Network Working Group M. Nystroem 
Request for Comments: 4793 RSA Security 
Category: Informational February 2007 


The EAP Protected One-Time Password Protocol (EAP-POTP) 
Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The IETF Trust (2007). 
Abstract 


This document describes a general Extensible Authentication Protocol 
(EAP) method suitable for use with One-Time Password (OTP) tokens, 
and offers particular advantages for tokens with direct electronic 
interfaces to their associated clients. The method can be used to 
provide unilateral or mutual authentication, and key material, in 
protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key 
Exchange Protocol Version 2 (IKEv2). 
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1. Introduction 
1.1. Scope 


This document describes an Extensible Authentication Protocol (EAP) 
[1] method suitable for use with One-Time Password (OTP) tokens, and 
offers particular advantages for tokens that are electronically 
connected to a user's computer, e.g., through a USB interface. The 
method can be used to provide unilateral or mutual authentication, 
and key material, in protocols utilizing EAP, such as PPP [10], IEEE 
802.1X [11], and IKEv2 [12]. 


1.2. Background 


A One-Time Password (OTP) token may be a handheld hardware device, a 
hardware device connected to a personal computer through an 
electronic interface such as USB, or a software module resident on a 
personal computer, which generates one-time passwords that may be 
used to authenticate a user towards some service. This document 
describes an EAP method intended to meet the needs of organizations 
wishing to use OTP tokens in an interoperable manner to authenticate 
users over EAP. The method is designed to be independent of 
particular OTP algorithms and to meet the requirements on modern EAP 
methods (see [13]). 


The basic variant of this method provides client authentication only. 
This mode is only to be used within a secured tunnel. A more 
advanced variant provides mutual authentication, integrity protection 
of the exchange, protection against eavesdroppers, and establishment 
of authenticated keying material. Both variants allow for fast 
session resumption. 


While this document also includes a profile of the general method for 
the RSA SecurID(TM) mechanism, it is described in terms of general 
constructions. It is therefore intended that the document will also 
serve as a framework for use with other OTP algorithms. 


Note: The term "OTP" as used herein shall not be confused with the 
EAP OTP method defined in [1]. 


1.3. Rationale behind the Design 


EAP-POTP has been designed with the intent that its messages and data 
elements be easily parsed by EAP implementations. This makes it 
easier to programmatically use the EAP method in the peer and the 
authenticator, reducing the need for user interactions and allowing 
for local generation of user prompts, when needed. In contrast, the 
Generic Token Card (GTC) method from [1], which uses text strings 
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generated by the EAP server, is intended to be interpreted and acted 
upon by humans. Furthermore, EAP-POTP allows for mutual 
authentication and establishment of keying material, which GTC does 
not. To retain the generic nature of GTC, the EAP-POTP method has 
been designed to support a wide range of OTP algorithms, with 
profiling expected for specific such algorithms. This document 
provides a profile of EAP-POTP for RSA SecurID tokens. 


1.4. Relationship with EAP Methods in RFC 3748 


The EAP OTP method defined in [1], which builds on [14], is an 
example of a particular OTP algorithm and is not related to the EAP 
method defined in this document, other than that a profile of EAP- 
POTP may be created for the OTP algorithm from [14]. 


The Generic Token Card EAP method defined in [1] is intended to work 
with a variety of OTP algorithms. The same is true for EAP-POTP, the 
EAP method defined herein. Advantages of profiling a particular OTP 
algorithm for use with EAP-POTP, compared to using EAP GTC, are 
described in Section 1.3. 


2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", and "MAY", in this document are to be 
interpreted as described in RFC 2119 [2]. 

3. Authentication Model 
The EAP-POTP method provides user authentication as defined below. 
Additionally, it may provide mutual authentication (authenticating 


the EAP server to the EAP client) and establish keying material. 


There are basically three entities in the authentication method 
described here: 


o A client, or "peer", using EAP terminology, acting on behalf of a 
user possessing an OTP token; 


o A server, or "authenticator", using EAP terminology, to which the 
user needs to authenticate; and 


o A backend authentication server, providing an authentication 
service to the authenticator. 


The term "EAP server" is used here with the same meaning as in [1]. 
Any protocol used between the authenticator and the backend 
authentication server is outside the scope of this document, although 
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RADIUS [15] is a typical choice. It is assumed that the EAP client 
and the peer are located on the same host, and hence only the term 
"peer" is used in the following for these entities. 


The EAP-POTP method assumes the use of a shared secret key, or 
"seed", which is known both by the user and the backend 
authentication server. The secret seed is stored on an OTP token 
that the user possesses, as well as on the authentication server. 


In its most basic variant, the EAP-POTP method provides only one 
Service (namely, user authentication) where the user provides 
information to the authentication server so that the server can 
authenticate the user. A more advanced variant provides mutual 
authentication, protection against eavesdropping, and establishment 
of authenticated keying material. 


4. Description of the EAP-POTP Method 
4.1. Overview 


Note: Since the EAP-POTP method is general in nature, the term 
"POTP-X" is used below as a placeholder for an EAP method type 
identifier, identifying the use of a particular OTP algorithm with 
EAP-POTP. As an example, in the case of using RSA SecurID tokens 
within EAP-POTP, the EAP method type shall be 32 (see Appendix A). 


A typical EAP-POTP authentication is performed as follows (Appendix B 
provides more detailed examples): 


a. The optional EAP Identity Request/Response is exchanged, as per 
REC 3748 [1]. An identity provided here may alleviate the need 
for a "User Identifier" or a "Token Key Identifier" triplet 
(TLV), defined below, later in the exchange. 


b. The EAP server sends an EAP-Request of type POTP-X with a Version 
TLV. The Version TLV indicates the highest and lowest version of 
this method supported by the server. The EAP server typically 
also includes an OTP TLV in the EAP-Request. The OTP TLV 
instructs the peer to respond with the current OTP (possibly in 
protected form), and may contain a challenge and some other 
information, like server policies. The EAP server should also 
include a Server-Info TLV in the request, and must do so if it 
supports session resumption. The Server-Info TLV identifies the 
authentication server, contains an identifier for this (new) 
session, and may be used by the peer to find an already existing 
session with the EAP server. 
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c. The peer responds with an EAP-Response of type Nak (3) if it does 
not support POTP-X or if it does not support a version of this 
method that is also supported by the server, as indicated in the 
server’s Version TLV. 


If the peer supports a version of this method that is also 
supported by the EAP server, the peer generates an EAP-Response 
of type POTP-X as follows: 


* First, it generates a Version TLV, which indicates the peer’s 
highest supported version within the range of versions offered 
by the server. This Version TLV will be part of the EAP- 
Response to the EAP server. 


* Next, if the peer's highest supported version equals that of 
the EAP server, and the EAP server sent a Server-Info TLV, the 
peer checks if it has a saved session with the EAP server. If 
an existing session with the server is found, and session 
resumption is possible (the Server-Info TLV may explicitly 
disallow it), the peer calculates new session keys (if the 
session is a protected-mode session) and responds with a 
Resume TLV and the Version TLV. 


* Otherwise, if the peer’s highest supported version equals that 
of the EAP server, and the received EAP-Request message 
contains an OTP TLV, the peer requests (possibly through user 
interaction) the OTP token to calculate a one-time password 
based on the information in the received EAP-Request message 
(which could, for example, carry a challenge), the current 
token state (e.g., token time), a shared secret (the "seed"), 
and a user-provided PIN (note that, depending on the OTP token 
type, some of the information in the EAP-Request may not be 
used in the OTP calculation, and the PIN may be optional too). 
If the received OTP TLV has the P bit set (see below), the 
peer then combines the token-provided OTP with other 
information, and provides the combined data to a key 
derivation function. The key derivation function generates 
several keys, of which one is used to calculate a Message 
Authentication Code (MAC) on the received message, together 
with some other information. The resulting MAC, together with 
some additional information, is then placed in an OTP TLV 
(with the P bit set) that is sent in a response to the EAP 
server, together with the Version TLV. If the P bit is not 
set in the received OTP TLV, the peer instead inserts the 
calculated OTP value directly in an OTP TLV, which then is 
sent to the EAP server together with the Version TLV. 
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* Finally, if the peer's highest supported version differs from 
the server's, or if the server did not provide any TLVs 
besides the Version TLV in its initial request, the peer just 
sends back the generated Version TLV as an EAP-Response to the 
EAP server. 


d. If the EAP server receives an EAP-Response of type Nak (3), the 
session negotiation failed and the EAP server may try with 
another EAP method. Otherwise, the EAP server checks the peer’s 
supported version. If the peer did not support the highest 
version supported by the server, the server will send a new EAP- 
Request with TLVs adjusted for that version. Otherwise, assuming 
the EAP server did send additional TLVs in its initial EAP- 
Request, the EAP server will attempt to authenticate the peer 
based on the response provided in c). Depending on the result of 
this authentication, the EAP server may do one of the following: 


* send a new EAP-Request of type POTP-X to the peer indicating 
that session resumption was not possible, and ask for a new 
OTP (this would be the case when the peer responded with a 
Resume TLV, and the session indicated in the Resume TLV was 
not valid), 


* send a new EAP-Request of type POTP-X to the peer (e.g., to 
ask for the next OTP), 


* accept the authentication (and send an EAP-Request message 
containing a Confirm TLV to the peer if the received response 
has the P bit set or was a successful attempt at a protected- 
mode session resumption; otherwise, send an EAP-Success 
message to the peer), or 


* fail the authentication (and send an EAP-Failure message -- 
possibly preceded by an EAP-Request message of type 
Notification (2) -- to the peer). 


e. If the peer receives an EAP-Success or an EAP-Failure message the 
protocol run is finished. If the peer receives an EAP-Request of 
type Notification, it responds as specified by RFC 3748 [1]. If 
the peer receives an EAP-Request of type POTP-X with a Confirm 
TLV, it attempts to authenticate the EAP server using the 
provided data. If the authentication is successful, the peer 
responds with an EAP-Response of type POTP-X with a Confirm TLV. 
If it is unsuccessful, the peer responds with an empty EAP- 
Response of type POTP-X. If the peer receives an EAP-Request of 
type POTP-X containing some other TLVs, it continues as specified 
in c) above (though no version negotiation will take place in 
this case) or as described for those TLVs. 
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f. When an EAP server, which has sent an EAP-Request of type POTP-X 
with a Confirm TLV, receives an EAP-Response of type POTP-X with 
a Confirm TLV present, it can proceed in one of two ways: If it 
has detected that there is a need to send additional EAP-Requests 
of type POTP-X, it shall enter a "protected state", where, from 
then on, all POTP-X TLVs must be encrypted and integrity- 
protected before being sent (at this point, the parties shall 
have calculated a master session key as described in Section 
4.5). One reason to continue the POTP-X conversation after 
exchange of the Confirm TLV could be that the user needs to 
update her OTP PIN; hence, the EAP server needs to send a New PIN 
TLV. At that point, the handshake is back at step c) above 
(except for the version negotiation and the protection of all 
TLVs). If there is no need to send additional EAP-Request 
packets, the EAP server shall instead send an EAP-Success method 
to the peer to indicate successful protocol completion. The EAP 
server may not continue the conversation unless it indicates its 
intent to do so in the Confirm TLV. 


An EAP server, which has sent an EAP-Request of type POTP-X with 
a Confirm TLV and receives an EAP-Response of type POTP-X, which 
is empty (i.e., does not contain any TLVs), shall respond with an 
EAP-Failure and terminate the handshake. 


As implied by the description, steps c) through f) may be carried out 
a number of times before completion of the exchange. One example of 
this is when the authentication server initially requests an OTP, 
accepts the response from the peer, performs an (intermediary) 
Confirm TLV exchange, requests the peer to select a new PIN, and 
finally asks the peer to authenticate with an OTP based on the new 
PIN (which again will be followed with a final Confirm TLV exchange). 


4.2. Version Negotiation 


The EAP-POTP method provides a version negotiation mechanism that 
enables implementations to be backward compatible with previous 
versions of the protocol. This specification documents the EAP-POTP 
protocol version 1. Version negotiation proceeds as follows: 


a. In the first EAP-Request of type POTP-X, the EAP server MUST send 
a Version TLV in which it sets the "Highest" field to its highest 
supported version number, and the "Lowest" field to its lowest 
supported version number. The EAP server MAY include other TLV 
triplets, as described below, that are compatible with the 
"Highest" supported version number to optimize the number of 
round-trips in the case of a peer supporting the server’s 
"Highest" version number. 
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b. If the peer supports a version of the protocol that falls within 
the range of versions indicated by the EAP server, it MUST 
respond with an EAP-Response of type POTP-X that contains a 
Version TLV with the "Highest" field set to the highest version 
supported by the peer. The peer MUST also respond to any TLV 
triplets included in the EAP-Request, if it supported the 
"Highest" supported version indicated in the server's Version 
TLV. 


The EAP peer MUST respond with an EAP-Response of type Nak (3) if 
it does not support a version that falls within the range of 
versions indicated by the EAP server. This will allow the EAP 
server to use another EAP method for peer authentication. 


C. When the EAP server receives an EAP-Response containing a Version 
TLV from the peer, but the "Highest" supported version field in 
the TLV differs from the "Highest" supported version field sent 
by the EAP server, or when the version is the same as the one 
originally proposed by the EAP server, but the EAP server did not 
include any TLV triplets in the initial request, the EAP server 
sends a new EAP-Request of type POTP-X with the negotiated 
version and TLV triplets as desired and described herein. 


The version negotiation procedure guarantees that the EAP peer and 
server will agree to the highest version supported by both parties. 
If version negotiation fails, use of EAP-POTP will not be possible, 
and another mutually acceptable EAP method will need to be negotiated 
if authentication is to proceed. 


The EAP-POTP version field may be modified in transit by an attacker. 
It is therefore important that EAP entities only accept EAP-POTP 
versions according to an explicit policy. 


4.3. Cryptographic Algorithm Negotiation 


Cryptographic algorithms are negotiated through the use of the Crypto 
Algorithm TLV. EAP-POTP provides a default digest algorithm 
(SHA-256) [3], a default encryption algorithm (AES-CBC) [4] , anda 
default MAC algorithm (HMAC) [5], and these algorithms MUST be 
supported by all EAP-POTP implementations. An EAP server that does 
not want to make use of any other algorithms than the default ones 
need not send a Crypto Algorithm TLV. An EAP server that does want 
to negotiate use of some other algorithms MUST send the Crypto 
Algorithm TLV in the initial EAP-Request of type POTP-X that also 
contains an OTP TLV with the P bit set. The TLV MUST NOT be present 
in any other EAP-Request in the session. (The two exceptions to this 
are 1) if the client attempted a session resumption that failed and 
therefore did not evaluate a sent Crypto Algorithm TLV, or 2) if the 
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Crypto Algorithm TLV was part of the initial message from the EAP 
server, and the client negotiated another EAP-POTP version than the 
highest one supported by the EAP server. When either of these cases 
apply, the server MUST include the Crypto Algorithm TLV in the first 
EAP-Request that also contains an OTP TLV with the P bit set 
subsequent to the failed session resumption / protocol version 
negotiation.) In the Crypto Algorithm TLV, the EAP server suggests 
some combination of digest, encryption, and MAC algorithms. (If the 
server only wants to negotiate a particular class of algorithms, then 
suggestions for the other classes need not be present, since the 
default applies.) 


The peer MUST include a Crypto Algorithm TLV in an EAP-Response if 
and only if an EAP-Request of type POTP-X has been received 
containing a Crypto Algorithm TLV, it was legal for that EAP-Request 
to contain a Crypto Algorithm TLV, the peer does not try to resume an 
existing session, and the peer and the EAP server agree on at least 
one algorithm not being the default one. If the peer does not supply 
a value for a particular class of algorithms in a responding Crypto 
Algorithm TLV, then the default algorithm applies for that class. 
When resuming an existing session (see the next section), there is no 
need for the peer to negotiate since the session already is 
associated with a set of algorithms. Servers MUST fail a session 
(i.e., send an EAP-Failure) if they receive an EAP-Response TLV 
containing both a Resume TLV and a Crypto Algorithm TLV. 


Clearly, EAP servers and peers MUST NOT suggest any other algorithms 
than the ones their policy allows them to use. Policies may also 
restrict what combinations of cryptographic algorithms are 
acceptable. 


4.4. Session Resumption 


This method makes use of session identifiers and server identifiers 
to allow for improved efficiency in the case where a peer repeatedly 
attempts to authenticate to an EAP server within a short period of 
time. This capability is particularly useful for support of wireless 
roaming. 


In order to help the peer find a session associated with the EAP 
server, an EAP server that supports session resumption MUST send a 
Server-Info TLV containing a server identifier in its initial EAP- 
Request of type POTP-X that also contains an OTP TLV. The identifier 
may then be used by the peer for lookup purposes. 


It is left to the peer whether or not to attempt to continue a 


previous session, thus shortening the negotiation. Typically, the 
peer’s decision will be made based on the time elapsed since the 
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previous authentication attempt to that EAP server. If the peer 
decides to attempt to resume a session with the EAP server, it sends 
a Resume TLV identifying the chosen session and other contents, as 
described below, to the EAP server. 


Based on the session identifier chosen by the peer, and the time 
elapsed since the previous authentication, the EAP server will decide 
whether to allow the session resumption, or continue with a new 
session. 


o If the EAP server is willing to resume a previously established 
session, it MUST authenticate the peer based on the contents of 
the Resume TLV. If the authentication succeeds, the handshake 
will continue in one of two ways: 


* If the session is a protected-mode session, then the server 
MUST respond with a request containing a Confirm TLV. If the 
Confirm TLV authenticates the EAP server, then the peer 
responds with an empty Confirm TLV, to which the EAP server 
responds with an EAP-Success message. If the Confirm TLV does 
not authenticate the EAP server, the peer responds with an 
empty EAP-Response of type POTP-X. 


* If the session is not a protected-mode session, i.e., it is a 
session created from a basic-mode peer authentication, then the 
server MUST respond with an EAP-Success message. 


If the authentication of the peer fails, the EAP server SHOULD 
send another EAP-Request containing an OTP TLV and a Server-Info 
TLV with the N bit set to indicate that no session resumption is 
possible. The EAP server MAY also send an EAP-Failure message, 
possibly preceded by an EAP-Request of type Notification (2), in 
which case, the EAP run will terminate. 


o If the EAP server is not willing or able to resume a previously 
established session, it will respond with another EAP-Request 
containing an OTP TLV and a Server-Info TLV with the N bit set 
(indicating no session resumption). 


Sessions SHOULD NOT be maintained longer than the security of the 
exchange which created the session permits. For example, if it is 
estimated that an attacker could be successful in brute-force 
searching for the OTP in 24 hours, then EAP-POTP session lifetimes 
should be clearly less than this value. 
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4.5. Key Derivation and Session Identifiers 


The EAP-POTP method described herein makes use of a key derivation 
function denoted "PBKDF2". PBKDF2 is described in [6], Section 5.2. 
The PBKDF2 PRF SHALL be set to the negotiated MAC algorithm. The 
default MAC algorithm, which MUST be supported, is HMAC-SHA256. HMAC 
is defined in [5], and SHA-256 is defined in [3]. HMAC-SHA256 is the 
HMAC construct from [5] with SHA-256 as the hash function H. The 
output length of HMAC-SHA256, when used as a PRF for PBKDF2, shall be 
32 octets (i.e., the full output length). 


The output from PBKDF2 as described here will consist of five keys 
(see Section 4.11.3 for details on how to calculate these keys): 


o K_MAC, a MAC key used for mutual authentication and integrity 
protection, 


o K_ENC, an encryption key used to protect certain data during the 
authentication, 


o SRK, a session resumption key only used for session resumption 
purposes, 


o MSK, a Master Session Key, as defined in [1], and 
o EMSK, an Extended Master Session Key, also as defined in [1]. 


For the default algorithms, K_MAC, K_ENC, and SRK SHALL be 16 


octets. For other cases, the key lengths will be as determined by 
the negotiated algorithms. The MSK and the EMSK SHALL each be 64 
octets, in conformance with [1]. Therefore, in the case of 


default algorithms, the "dkLen" parameter from Section 5.2 of [6] 
SHALL be set to 176 (the combined length of K_MAC, K_ENC, SRK, 
MSK, and EMSK). 


[1] and [16] define usage of the MSK and the EMSK . For a particular 
use case, see also Appendix C. 


4.6. Error Handling and Result Indications 


EAP does not allow for the sending of an EAP-Response of type Nak (3) 
within a method after the initial EAP-Request and EAP-Response pair 
of that particular method has been exchanged (see [1], Section 2.1). 
Instead, when a peer is unable to continue an EAP-POTP session, the 
peer MAY respond to an outstanding EAP-Request by sending an empty 
EAP-Response of type POTP-X rather than immediately terminating the 
conversation. This allows the EAP server to log the cause of the 
error. 


Nystroem Informational [Page 13] 


RFC 4793 EAP-POTP February 2007 


To ensure that the EAP server receives the empty EAP-Response, the 
peer SHOULD wait for the EAP server to reply before terminating the 
conversation. The EAP server MUST reply with an EAP-Failure. 


When EAP-POTP is run in protected mode, the exchange of the Confirm 
TLV (Section 4.11.6) serves as a success result indication; when the 
peer receives a Confirm TLV, it knows that the EAP server has 
successfully authenticated it. Similarly, when the EAP server 
receives the Confirm TLV response from the peer, it knows that the 
peer has authenticated it. In protected mode, the peer will not 
accept an EAP-Success packet unless it has received and validated a 
Confirm TLV. The Confirm TLV sent from the EAP server to the peer is 
a "protected result indication" as defined in [1], as it is integrity 
protected and cannot be replayed. The Confirm TLV sent from the peer 
to the EAP server is, however, not a protected result indication. An 
empty EAP-POTP response sent from the peer to the EAP server serves 
as a failure result indication. 


4.7. Use of the EAP Notification Method 


Except where explicitly allowed in the following, the EAP 
Notification method MUST NOT be used within an EAP-POTP session. The 
EAP Notification method MAY be used within an EAP-POTP session in the 
following situations: 


o The EAP server MAY send an EAP-Request of type Notification (2) 
when it has received an EAP-Response containing an OTP TLV and is 
unable to authenticate the user. In this case, once the EAP- 
Response of type Notification is received, the EAP server MAY 
retry the authentication and send a new EAP-Request containing an 
OTP TLV, or it MAY fail the session and send an EAP-Failure 
message. 


o The EAP server MAY send an EAP-Request of type Notification (2) 
when it has received an unacceptable New PIN TLV. In this case, 
once the EAP-Response of type Notification is received, the EAP 
server MAY retry the PIN update and send a new EAP-Request with a 
New PIN TLV, or it MAY fail the session and send an EAP-Failure 
message. 


4.8. Protection against Brute-Force Attacks 


Since OTPs may be relatively short, it is important to slow down an 
attacker sufficiently so that it is economically unattractive to 
brute-force search for an OTP, given an observed EAP-POTP handshake 
in protected mode. One way to do this is to do a high number of 
iterated hashes in the PBKDF2 function. Another is for the client to 
include a value ("pepper") unknown to the attacker in the hash 
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computation. Whereas a traditional "salt" value normally is sent in 
the clear, this "pepper" value will not be sent in the clear, but may 
instead be transferred to the EAP server in encrypted form. In 
practice, the procedure is as follows: 


a. The EAP server indicates in its OTP TLV whether it supports 
pepper searching. Additionally, it may indicate to the peer that 
a new pepper shall be chosen. 


b. If the peer supports the use of pepper, the peer checks whether 
it already has established a shared pepper with this server: 


If it does have a pepper stored for this server, and the server 
did not indicate that a new pepper shall be generated, then it 
uses the existing pepper value, as specified in Section 4.11.3 
below, to calculate an OTP TLV response. In this case, the 
iteration count shall be kept to a minimum, as the security of 
the scheme is provided through the pepper, and efficiency 
otherwise is lost. 


If the peer does not have a pepper stored for this server, but 
the server indicated support for pepper searching, or the server 
indicated that a new pepper shall be generated, then the peer 
generates a random and uniformly distributed pepper of sufficient 
length (the maximum length supported by the server is provided in 
the server’s OTP TLV), and includes the new pepper in the PBKDF2 
computation. 


If the peer does not have a pepper stored for this server, and 
the server did not indicate support for pepper searching, then a 
pepper will not be used in the response computation. 


Clearly, if the peer itself does not support the use of pepper, 
then a pepper will not be used in the response computation. 


c. The EAP server may, in its subsequent Confirm TLV, provide a 
pepper to the peer for later use. In this case, the pepper will 
be substantially longer than a peer-chosen pepper, and encrypted 
with a key derived from the PBKDF2 computation. 


The above procedure allows for pepper updates to be initiated by 
either side, e.g., based on policy. Since the pepper can be seen as 
a MAC key, its lifetime should be limited. 


An EAP server that is not capable of storing pepper values for each 
user it is authenticating may still support the use of pepper; the 
cost for this will be the extra computation time to do pepper 
searches. This cost is still substantially lower than the cost for 
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an attacker, however, since the server already knows the underlying 
OTP. 


4.9. MAC Calculations in EAP-POTP 
4.9.1. Introduction 
In protected mode, EAP-POTP uses MACs for authentication purposes, as 
well as to ensure the integrity of protocol sessions. This section 
defines how the MACs are calculated and the rationale for the design. 
4.9.2. MAC Calculation 
In protected mode, and when resuming a previous session, rather than 
sending authenticating credentials (such as one-time passwords or 
shared keys) directly, evidence of knowledge of the credentials is 
sent. This evidence is a MAC on the hash of (certain parts of) EAP- 
POTP messages exchanged so far in a session using a key K_MAC: 
mac = MAC(K_MAC, msg_hash(msg_l, msg_2, ..., msg_n)) 
where 
"MAC" is the negotiated MAC algorithm, "K_MAC" is a key derived as 
specified in Section 4.5, and "msg_hash(msg_l, msg_2, ..., msg_n)" is 


the message hash defined below of messages msg_l, msg_2, ..., msg_n. 


4.9.3. Message Hash Algorithm 


To compute a message hash for the MAC, given a sequence of EAP 
messages msg_1, msg_2, ..., msg_n, the following operations shall be 
carried out: 


a. Re-transmitted messages are removed from the sequence of 
messages. 


Note: The resulting sequence of messages must be an alternating 
sequence of EAP Request and EAP Response messages. 


b. The contents (i.e., starting with the EAP "Type" field and 
excluding the EAP "Code", "Identifier", and "Length" fields) of 
each message, msg_1, msg_2, ..., msg_n, is concatenated together. 


c. User identifier TLVs MUST NOT be included in the hash (this is to 
allow for a backend service that does not know about individual 
user names), i.e., any such TLV is removed from the message in 
which it appeared. 
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d. The resulting string is hashed using the negotiated hash 
algorithm. 


4.9.4. Design Rationale 


The reason for excluding the "Identifier" field is that the actual, 
transmitted "Identifier" field is not always known to the EAP method 
layer. The reason for excluding the "Length" field is to allow the 
possibility for an intermediary to remove or replace a Username TLV 
(e.g., for anonymity or service reasons) before passing a received 
response on to an authentication server. While this on the surface 
may appear as bad security practice, it may in practice only result 
in denial of service, something which always may be achieved by an 
attacker able to modify messages in transit. By excluding the "Code" 
field, the hash is simply calculated on applicable sent and received 
message contents. Excluding the "Code" field is regarded as harmless 
since the hash is to be made on the sequence of POTP-X messages, all 
having alternating (known) Code values, namely 1 (Request) and 2 
(Response). 


4.9.5. Implementation Considerations 


To save on storage space, each EAP entity may partially hash messages 
as they are sent and received (e.g., HashInit(); HashUpdate (message 
1); ...; HashUpdate (message n-1); HashFinal (message n)). This 
reduces the amount of state needed for this purpose to the internal 
state required for the negotiated hash algorithm. 


4.10. EAP-POTP Packet Format 


A summary of the EAP-POTP packet format is shown below. The fields 
are transmitted from left to right. 


0 1 2 3 
01-23 4 S267 8 90. 12) 3) A 6 8 9 OL 2 34946) 7 849-401 
E 


| Code | Identifier | Length 
tata A tata tata tata ta ta tata ta tata tata ta ++ ta tat +++ +++ +++ 
| Type | Reserved | TLV-based EAP-POTP message 


+—+-4+-4+-—4+-4+-4+-—4+-4+-4+-4+-4-4+-t-4t-4+-4-4t-4-4+-t-t-4+-t-t-4+-4+-4t-4t-4+-4t-4-4+ 
Code 
1 - Request 


2 - Response 
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Identifier 


The Identifier field is 1 octet and aids in matching responses 
with requests. For a more detailed description of this field and 
how to use it, see [1]. 


Length 


The Length field is 2 octets and indicates the length of the EAP 
packet including the Code, Identifier, Length, Type, Version, 
Flags, and TLV-based EAP-POTP message fields. 


Type 
Identifies use of a particular OTP algorithm with EAP-POTP. 
Reserved 


This octet is reserved for future use. It SHALL be set to zero 
for this version. Recipients SHALL ignore this octet for this 
version of EAP-POTP. 


TLV-based EAP-POTP message 


This field will contain 0, 1, or more Type-Length-Value triplets 
defined as follows (this is similar to the EAP-TLV TLVs defined in 
PEAPv2 [17], and the explanation of the generic fields is borrowed 
from that document). 


0 1 2 3 
OLEA O 8 Or ds 2.3 4 So 6 7 8: 97:00 1.2003 AR 3: 06) 718 OO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|M|R| TLV Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


M 
0 - Non-mandatory TLV 
1 - Mandatory TLV 
The TLVs within EAP POTP-X are used to carry parameters between 
the EAP peer and the EAP server. An EAP peer may not necessarily 
implement all the TLVs supported by an EAP server, and to allow 


for interoperability, a special TLV allows an EAP server to 
discover if a TLV is supported by the EAP peer. 
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The mandatory bit in a TLV indicates that if the peer or server 
does not support the TLV, it MUST send a NAK TLV in response; all 
other TLVs in the message MUST be ignored. If an EAP peer or 
server finds an unsupported TLV that is marked as non-mandatory 
(i.e., optional), it MUST NOT send a NAK TLV on this ground only. 


The mandatory bit does not imply that the peer or server is 
required to understand the contents of the TLV. The appropriate 
response to a supported TLV with content that is not understood is 
defined by the specification of the particular TLV. 


R 
Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of the EAP-POTP. 
TLV Type 
The following TLV types are defined for use with EAP-POTP: 
0 - Reserved for future use 
1 - Version 
2 - Server-Info 
3 ==OTP 
4 -— NAK 
5 -— New PIN 
6 - Confirm 
7 — Vendor-Specific 
8 - Resume 
9 - User Identifier 
10 - Token Key Identifier 
11 - Time Stamp 
12 - Counter 
13 - Keep-Alive 
14 - Protected 
15 - Crypto Algorithm 
16 - Challenge 
These TLVs are defined in the following. With the exception of 
the NAK TLV, a particular TLV type MUST NOT appear more than once 
in a message of type POTP-X. 
Length 


The length of the Value field in octets. 


Nystroem Informational [Page 19] 


RFC 4793 EAP-POTP February 2007 


Value 
The value of the TLV. 
4.11. EAP-POTP TLV Objects 
4.11.1. Version TLV 


The Version TLV carries information about the supported EAP-POTP 
method version. 


This TLV MUST be present in the initial EAP-Request of type POTP-X 
from the EAP server and in the initial response of type POTP-X from 
the peer. It MUST NOT be present in any subsequent EAP-Request or 
EAP-Response in the session. The Version TLV MUST be supported by 
all peers, and all EAP servers conforming to this specification and 
MUST NOT be responded to with a NAK TLV. The version negotiation 
procedure is described in detail in Section 4.2. 


0 1 2 3 
O12 345 6783 9 012345678 9012-345 678 9 0-1 
E 


|M|R| TLV Type | Length | 
Fatt ata ta tata tartar a o o o O 
| Reserved | Highest | Lowest 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


M 
1 - Mandatory TLV 

R 
Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 

TLV Type 
1 

Length 


3 in EAP-Requests, 2 in EAP-Responses 
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Reserved 
Reserved for future use. This octet MUST be set to zero for this 
version. Recipients SHALL ignore this octet for this version of 
EAP-POTP. 

Highest 


This field contains an unsigned integer representing the highest 
protocol version supported by the sender. If a value provided by 
a peer to an EAP server falls between the server’s "Highest" and 
"Lowest" supported version (inclusive), then that value will be 
the negotiated version for the authentication session. 


Lowest 


This field contains an unsigned integer representing the lowest 
version acceptable by the EAP server. The field MUST be present 
in an EAP-Request. The field MUST NOT be present in an EAP- 
Response. A peer SHALL respond to an EAP-Request of type POTP-X 
with an EAP-Response of type Nak (3) if the peer’s highest 
supported version is lower than the value of this field. 


This document defines version 1 of the protocol. Therefore, EAP 
server implementations conforming to this document SHALL set the 
"Highest" field to 1. Peer implementations conforming to this 


document SHALL set the "Highest" field to 1. 
4.11.2. Server-Info TLV 


The Server-Info TLV carries information about the EAP server and the 
session (when applicable). It provides one piece in the framework 
for fast session resumption. 


This TLV SHOULD always be present in an EAP-Request of type POTP-X 
that also carries an OTP TLV, as long as the peer has not been 
authenticated, and MUST be present in such a request if the server 
supports session resumption. It MUST NOT be present in any other 
EAP-Request of type POTP-X or in any EAP-Response packets. This TLV 
type MUST be supported by all peers conforming to this specification 
and MUST NOT be responded to with a NAK TLV (this is not to say that 
all peers need to support session resumption, only that they cannot 
respond to this TLV with a NAK TLV). 
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0 £ 2 3 
Od 2534 96. Y 89:01:23 4 56:41 8: G0 ak 2" 34-506: 7.8 9:01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|M|R| TLV Type | Length | 
E toto ta tatatatatototo ta tatatatititatotetetatat 
Reserved |N| Session Identifier 


UE acres A INS le A. 
| Session Identifier (continued) 

Fatt tata tata tartar a o o o E O 
|Sess.Id (cont.) | Nonce ... (16 octets) 

Fatt ata ta tata t arta a a a o E O 
| Server Identifier 

Fatt rt ata tata tartar a o o o o O 


M 
1 - Mandatory TLV 

R 
Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 

TLV Type 
2 

Length 
25 + length of Server Identifier field 

Reserved 
Reserved for future use. All 7 bits MUST be set to zero for this 
version. Recipients SHALL ignore this bit for this version of 
EAP-POTP. 

N 


The N bit signals that the peer MUST NOT attempt to resume any 
session it has stored associated with this server. 


Nystroem Informational [Page 22] 


RFC 4793 EAP-POTP February 2007 


Session Identifier 


An 8-octet identifier for the session about to be negotiated. 
Note that, in the case of session resumption, this session 
identifier will not be used (the session identifier for the 
resumed session will continue to be used). 


Nonce 


A l6-octet nonce chosen by the server. During session resumption, 
this nonce is used when calculating new K_ENC, K_MAC, SRK, MSK, 
and EMSK keys as specified below. 


Server Identifier 


An identifier for the authentication server. The peer MAY use 
this identifier to search for a stored session associated with 
this server, or to associate the session to be negotiated with the 
server. The value of the identifier SHOULD be chosen so as to 
reduce the risk of collisions with other EAP server identifiers as 
much as possible. One possibility is to use the DNS name of the 
EAP server. The identifier MAY also be used by the peer to select 
a suitable key on the OTP token (when there are multiple keys 
available). 


The identifier MUST NOT be longer than 128 octets. The identifier 
SHALL be a UTF-8 [7] encoded string of printable characters 
(without any terminating NULL character). 


4211.3. OTP TLV 


In an EAP-Request, the OTP TLV is used to request an OTP (or a value 
derived from an OTP) from the peer. In an EAP-Response, the OTP TLV 
carries an OTP or a value derived from an OTP. 


This TLV type MUST be supported by all peers and all EAP servers 
conforming to this specification and MUST NOT be responded to with a 
NAK TLV. The OTP TLV MUST NOT be present in an EAP-Request of type 
POTP-X that contains a New PIN TLV. Further, the OTP TLV MUST NOT be 
present in an EAP-Response of type POTP-X unless the preceding EAP- 
Request of type POTP-X contained an OTP TLV and it was valid for it 
to do so. Finally, an OTP TLV MUST NOT be present in an EAP- 
Response of type POTP-X that also contains a Resume TLV. The OTP TLV 
is defined as follows: 
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0 £ 2 3 
0:01, 2534 96. Y 89:07 1:23 4: 56:41 8: Gi ak 2" 34-506: 7.8 9:01 
E 


|M|R| TLV Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Reserved |A|P|c|N|T|E|S| Pepper Length |Iteration Count | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Iteration Count (cont.) | Auth. Data | 


+—t-F-4-4-4-4F-4-4-4-4F 4-4-4 II 
| Authentication Data (cont.) 
+—t-f-4-4-4-F-4-4-F-F 4-4-4 II FHF HF FF HF Ft tit 


M 
1 - Mandatory TLV 

R 
Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 

TLV Type 
3 

Length 
7 + length of Authentication Data field 

Reserved 
Reserved for future use. All 9 bits SHALL be set to zero (0) for 
this version. Recipients SHALL ignore these bits for this version 
of EAP-POTP. 

A 


The A bit MUST be set in an EAP-Request if and only if the request 
immediately follows an EAP-Response of type POTP-X containing a 
New PIN TLV (see Section 4.11.5), and the new PIN in the response 
was accepted by the EAP server. In this case, the A bit signals 
that the EAP-server has accepted the PIN, and that the peer SHALL 
use the newly established PIN when calculating the response (when 
applicable). The A bit MUST NOT be set if the S bit is set. Ifa 
request has both the S bit and the A bit set, the peer SHALL 
regard the request as invalid, and return an empty POTP-X EAP- 
Response message. 
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In an EAP-Response, the A bit, when set, indicates that the OTP 
was calculated with the use of the newly selected user PIN. The A 
bit MUST be set in a response if and only if the EAP-Request which 
triggered the response contained an OTP TLV with the A bit set. 


P 
In an EAP-Request, the P bit indicates that the OTP in the 
response MUST be protected. Use of this bit also indicates that 
mutual authentication will take place, as well as generation of 
keying material. It is RECOMMENDED to always set the P bit. Ifa 
peer receives an EAP-Request with an OTP TLV that does not have 
the P bit set, and the peer’s policy dictates protected mode, the 
peer MUST respond with an empty POTP-X EAP-Response message. All 
peers MUST support protected mode. 
In an EAP-Response, this bit indicates that the provided OTP has 
been protected (see below). The P bit MUST be set in a response 
(and hence the OTP MUST be protected) if and only if the EAP- 
Request that triggered the response contained an OTP TLV with the 
P bit set. 
In an 802.1x EAP over LAN (EAPOL) environment (this includes 
wireless LAN environments), the P bit MUST be set, or, 
alternatively, the EAP-POTP method MUST be carried out inside an 
authenticated tunnel that provides a cryptographic binding with 
inner EAP methods such as the one provided by PEAPv2 [17]. 

C 


The C bit carries meaning only when the OTP algorithm in question 
makes use of server challenges. For other OTP algorithms, the C 
bit SHALL always be set to zero. 


In an EAP-Request, the C bit ("Combine") indicates that the OTP 
SHALL be calculated using both the provided challenge and internal 
state (e.g., current token time). The OTP SHALL be calculated 
based only on the provided challenge (and the shared secret) if 
the C bit is not set, and a challenge is present. The returned 
OTP SHALL always be calculated based on the peer’s current state 
(and the shared secret) if no challenge is present. If the C bit 
is set but no challenge is provided, the peer SHALL regard the 
request as invalid, and return an empty POTP-X EAP-Response 
message. 
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In an EAP response, this bit indicates that the provided OTP has 
been calculated using a provided challenge and the token state. 
The C bit MUST be set in a response if and only if the EAP-Request 
that triggered the response contained an OTP TLV with the C bit 
set and a challenge. 


In an EAP-Request, the N bit, when set, indicates that the OTP to 
calculate SHALL be based on the next token "state", and not the 
current one. As an example, for a time-based token, this means 
the next time slot. For an event-based token, this could mean the 
next counter value, if counter values are used. This bit will 
normally not be set in initial EAP-Request messages, but may be 
set in subsequent ones. Further, the N bit carries no meaning in 
an EAP-Request if a challenge is present and the C bit is not set, 
and SHALL be set to 0, in this case. If a request that has the N 
bit set also contains a challenge, but does not have the C bit 
set, the peer SHALL regard the request as invalid, and return an 
empty POTP-X EAP-Response message. Note that setting the N bit in 
an EAP-Request will normally advance the internal state of the 
token. 


In an EAP-Response, the N bit, when set, indicates that the OTP 
was calculated based on the next token "state" (as explained 
above), and not the current one. The N bit MUST be set ina 
response if and only if the EAP-Request that triggered the 
response contained an OTP TLV with the N bit set. 


The T bit only carries meaning for OTP methods normally 
incorporating a user PIN in the OTP computation. 


In an EAP-Request, the T bit, when set, indicates that the OTP to 
calculate MUST NOT include a user PIN. 


In an EAP-Response, the T bit, when set, indicates that the OTP 
was calculated without the use of a user PIN. The T bit MUST be 
set in a response if and only if the EAP-Request that triggered 
the response contained an OTP TLV with the T bit set. Note that 
client policy may prohibit PIN-less calculations; in these cases, 
the client MAY respond with an empty POTP-X EAP response message. 


Nystroem Informational [Page 26] 


RFC 4793 EAP-POTP February 2007 


In an EAP-Request, the E bit, when set, indicates that the peer 
MUST NOT use any stored pepper value associated with this server 
in the PBKDF2 computation. Rather, it MUST generate a new pepper 
(if supported by the peer) and/or use the iteration count 
parameter to protect the OTP (if the server’s Max Pepper Length is 
0, then the peer MUST rely on the iteration count only to protect 
the OTP). This bit will usually not be set in initial EAP-Request 
messages, but may be set in subsequent ones, e.g., if the server, 
upon receipt of an OTP TLV with a pepper identifier, detects that 
it does not have a pepper with that identifier in storage. This 
bit carries no meaning, and MUST be set to zero, when the P bit is 
not set. If a request has the E bit set but not the P bit, a peer 
SHALL regard the request as invalid, and return an empty POTP-X 
EAP-Response message. 


In an EAP-Response, the E bit indicates that the response has been 
calculated without use of any stored pepper value. 


In an EAP-Request, the S bit ("Same"), when set, indicates that 
the peer SHOULD calculate its response based on the same OTP value 
as was used for the preceding response. This bit MAY be set when 
the EAP server has received an OTP TLV from the peer protected 
with a pepper, of which the server is no longer in possession. 
Since the server has not attempted validation of the provided 
data, there is no need for the EAP peer to retrieve a new OTP 
value. This bit carries no meaning, and MUST be set to zero, when 
the E bit is not set. A peer SHALL regard a request where the S 
bit is set, but not the E bit, as invalid, and return an empty 
POTP-X EAP-Response message. Further, the S bit MUST NOT be set 
when the A bit also is set; see above. 


In an EAP-Response, the S bit is never set. 
Pepper Length 


This octet SHALL be present if and only if the P bit is set. When 
present, it contains an unsigned integer, having a value between 0 
and 255 (inclusive). In an EAP-Request, the integer represents 
the maximum length (in bits) of a client-generated pepper the 
server is prepared to search for. Peers MUST NOT generate peppers 
longer than this value. If the value is set to zero, it means the 
peer MUST NOT generate a pepper for the PBKDF2 calculation. In an 
EAP-Response, it indicates the length of the used pepper. 
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Iteration Count 


These 4 octets SHALL be present if and only if the P bit is set. 
When present, they contain an unsigned, 4-octet integer in network 
byte order. In an EAP-Request, the integer represents the maximum 
iteration count the peer may use in the PBKDF2 computation. Peers 
MUST NOT use iteration counts higher than this value. In an EAP- 
Response, it indicates the actual iteration count used. 


Note regarding the Pepper Length and Iteration Count parameters: A 
peer MUST compare these policy parameters provided by the EAP server 
with local policy and MUST NOT continue the handshake if use of the 
EAP server’s suggested parameters would result in a lower security 
than the client’s acceptable policy. If the security given by the 
EAP server’s provided policy parameters surpasses the security level 
given by the peer’s local policy, the client SHOULD use the server’s 
parameters (subject to reason - active attackers could otherwise 
mount simple denial-of-service attacks against peers or servers, 
e.g., by providing unreasonably high values for the iteration count). 
Note that the server-provided parameters only apply to the case where 
the peer cannot use or does not have a previously provided server- 
provided pepper. If a peer cannot continue the handshake due to the 
server’s policy being unacceptable, it MUST return an empty POTP-X 
EAP-Response message. 


Authentication Data 


EAP-Request: In an EAP-Request, the Authentication Data field, when 
present, contains an optional "challenge". The challenge is an 
octet string that SHOULD be uniquely generated for each request in 
which it is present (i.e., it is a "nonce"), and SHOULD be 8 
octets or longer. To avoid fragmentation (i.e., EAP messages 
longer than the minimum EAP MTU size; see [1]), the challenge MUST 
NOT be longer than 64 octets. When the challenge is not present, 
the OTP will be calculated on the current token state only. The 
peer MAY ignore a provided challenge if and only if the OTP token 
the peer is interacting with is not capable of including a 


challenge in the OTP calculation. In this case, EAP server 
policies will determine whether or not to accept a provided OTP 
value. 


EAP-Response: The following applies to the Authentication Data field 
in an EAP-Response: 


* When the P bit is not set, the peer SHALL directly place the 


OTP value calculated by the token in the Authentication Data 
field. In this case, the EAP server MUST NOT send a Confirm 
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TLV upon successful authentication of the peer (instead, it 
sends an EAP-Success message). 


When the P bit is set, the peer SHALL populate this field as 
follows. After the token has calculated the OTP value, the 
peer SHALL compute: 


K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(otp, salt | pepper 
| auth_id, iteration_count, key_length) 


where 

"|" denotes concatenation, 

"otp" is the already computed OTP value, 
"salt" is a 16-octet nonce, 


"pepper" is an optional nonce (at most, 255 bits long, and, 
if necessary, padded to be a multiple of 8 bits long; see 
below) included to complicate the task of finding a matching 
"otp" value for an attacker, 


"auth_id" is an identifier (at most, 255 octets in length) 
for the authenticator (i.e., the network access server) as 
reported by lower layers and as specified below, 


"iteration_count" is an iteration count chosen such that the 
computation time on the peer is acceptable (based on the 
server’s indicated policy and the peer’s local policy), 
while an attacker, having observed the response and 
initiating a search for a matching OTP, will be sufficiently 
slowed down. The "iteration_count" value MUST be chosen to 
provide a suitable level of protection (e.g., at least 
100,000) unless a server-provided pepper is being used, in 
which case, it SHOULD be 1. 


"key_length" is the combined length of the desired key 
material, in octets. When the default algorithms are used, 
key_length is 176. 


The "pepper" values are only included in PBKDF2 calculations 
and are never sent to EAP servers (though the peers do send 
their length, in bits). The purpose of the pepper values 
are, as mentioned above, to slow down an attacker’s search 
for a matching OTP, while not slowing down the peer (which 
iterated hashes do). If the pepper has been generated by 
the peer, and the chosen pepper length in bits is not a 
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multiple of 8, then the pepper value SHALL be padded to the 
left, with ’0’ bits to the nearest multiple of 8 before 
being used in the PBKDF2 calculation. This is to ensure the 
input to the calculation consists only of whole octets. As 
an example, if the chosen pepper length is 4, the pepper 
value will be padded to the left, with 4 '0' bits to form an 
octet before being used in the PBKDF2 calculation. 


When pepper is used, it is RECOMMENDED that the length of 
the pepper and the iteration count are chosen in such a way 
that it is computationally infeasible/unattractive for an 
attacker to brute-force search for the given OTP within the 
lifetime of that OTP. 


As mentioned previously, a peer MUST NOT include a newly 
generated pepper value in the PBKDF2 computation if the 
server did not indicate its support for pepper searching in 
this session. If the server did not indicate support for 
pepper searching, then the PBKDF2 computation MUST be 
carried out with a sufficiently higher number of iterations 
so as to compensate for the lack of pepper (see further 
Appendix D). 


A server may, in an earlier session, have transferred a 
pepper value to the peer in a Confirm TLV (see below). When 
this is the case, and the peer still has that pepper value 
stored for this server, the peer MUST NOT generate a new 
pepper but MUST, instead, use this transferred pepper value 
in the PBKDF2 calculations. The only exception to this is 
when a local policy (e.g., timer) dictates that the peer 
must switch to a new pepper (and the server indicated 
support for pepper searching). 


The following applies to the auth_id component: 


- For dial-up, "auth_id" SHALL be either the empty string 
or the phone number called by the peer. The phone number 
SHALL be specified in the form of a URL conformant with 
RFC 3966 [8], e.g., "tel:+16175550101". Processing of 
received phone numbers SHALL be conformant with RFC 3966 
(this assumes that "tel" URIs will be shorter than 256 
octets, which would normally be the case). 


= For use with IEEE 802.1X, "auth_id" SHALL be either the 
empty string or the MAC address of the authenticator in 
canonical binary format (6 octets). 
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- For IP-based EAP, "auth_id" SHALL be either the empty 
string or the IPv4 or IPv6 address of the authenticator 
as seen by the peer and in binary format (4 or 16 octets, 
respectively). As an example, the IPv4 address 
"192.0.2.5" would be represented as (in hex) CO 00 02 05, 
whereas the IPv6 address "2001:DB8::101" would be 
represented as (in hex) 20 01 0D B8 00 00 00 00 00 00 00 
00 00 00 01 01. 


Note: Use of the authenticator’s identifying information 
within the computation aids in protection against man-in- 
the-middle attacks, where a rogue authenticator seeks to 
intercept and forward the Authentication Data in order to 
impersonate the peer at a legitimate authenticator (but see 
also the discussion around spoofed authenticator addresses 
in Section 6). For these reasons, a peer SHOULD NOT set the 
auth_id component to the empty string unless it is unable to 
learn the identifying information of the authenticator. In 
these cases, the EAP server’s policy will determine whether 
or not the session may continue. 


As an example, when otp = "12345678", salt = 
0x54434534543445435465768789099880, pepper is not used, 
auth_id = "192.0.2.5", iteration_count = 2000 (decimal), and 


key_length = 176 (decimal), the input to the PBKDF2 
calculation will be (first two parameters in hex, line wrap 
for readability): 


(3132333435363738, 54434534543445435465768789099880 | 
c0000205, 2000, 176) 


As described, when the default algorithms are used, K_MAC is 
the first 16 octets of the output from PBKDF2, K_ENC the 
next 16 octets, MSK the following 64 octets, EMSK the next 
64 octets, and SRK the final 16 octets. Using K_MAC, the 
peer calculates: 


mac = MAC(K_MAC, msg_hash(msg_l, msg_2, ..., msg_n)) 


as specified in Section 4.9 and where msg_l, msg_2, ..., 
msg_n is a sequence of all EAP messages of type POTP-X 
exchanged so far in this session, as sent and received by 
the peer (for the peer’s initial MAC, it will typically be 
just one message: the EAP server’s initial EAP-Request of 
type POTP-X). 
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The peer then places the first 16 octets of "mac" in the 
Authentication Data field, followed by the "salt" value, 
followed by one octet representing the length of the 
"auth_id" value in octets, followed by the actual "auth_id" 
value in binary form, and optionally followed by a pepper 
identifier (only when the peer made use of a pepper value 
previously provided by the EAP server). Pepper identifiers, 
when present, are always 4 octets. All variables SHALL be 
present in the form they were input to the PBKDF2 algorithm. 
This will result in the Authentication Data field being 33 + 
(length of auth_id in octets) + (4, for pepper identifier, 
when present) octets in length. 


Continuing the previous example, the Authentication Data 
field will be populated with (in hex, line wrap for 
readability): 


< 16 octets of mac > | 54434534543445435465768789099880 | 
04 | c0000205 


Note: Since in this case (i.e., when the P bit is set) 
successful authentication of the peer by the EAP server will 
be followed by the transmission of an EAP-Request of type 
POTP-X containing a Confirm TLV for mutual authentication, 
the peer MUST save either all the input parameters to the 
PBKDF2 computation or the keys K_MAC, K_ENC, SRK, MSK, and 
EMSK (recommended, since they will be used later). This is 
because the peer cannot be guaranteed to be able to generate 
the same OTP value again. For the same reason (the Confirm- 
TLV from the EAP server), the peer MUST also store either 
the hash of the contents of the sent EAP-Response or the 
EAP-Response itself (but see the note above about not 
including any User Identifier TLVs in the hash computation). 


Given a set of possible OTP values, the authentication 
server verifies an authentication request from the peer by 
computing 


K_MAC’ | K_ENC’ | MSK’ | EMSK’ | SRK’ = PBKDF2 (otp’, 
salt | pepper’ | auth_id, iteration_count, key_length) 


for each possible OTP value otp’ and each possible pepper 
value pepper’ , and the provided values for salt, 
authenticator identity, and iteration count, as well as the 
applicable key length (default: 176). Note: Doing the 
computation for each possible pepper value implements the 
pepper search mentioned elsewhere in this document. Note 
also that the EAP server may accept more than one OTP value 
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at a given time, e.g., due to clock drift in the token. If 
the given pepper length is not a multiple of 8, each tested 
pepper value will be padded to the left to the nearest 
multiple of 8, in the same manner as was done by the peer. 
If the server already shares a secret pepper value with this 
peer, then obviously there will only be one possible pepper 
value, and the server will find it based on the 
pepper_identifier provided by the peer. The server SHALL 
send a new EAP-Request of type POTP-X with an OTP TLV with 
the E bit set if the peer provided a pepper identifier 
unknown to the server. 


For each K_MAC’, the EAP server computes 
mac’ = MAC(K_MAC’, msg_hash(msg_1', msg_2’, ..., msg_n')) 


where MAC is the negotiated MAC algorithm, msg_hash is the 
message hash algorithm defined in Section 4.9, and msg_1', 


msg_2’, ... msg_n’ are the same messages on which the peer 
calculated its message hash, but this time, as sent and 
received by the EAP server. If the first 16 octets of mac’ 


matches the first 16 octets in the Authentication Data field 
of the EAP-Response in question, and the provided 
authenticator identity is acceptable (e.g., matches the EAP 
server’s view of the authenticator’s identity), then the 
peer is authenticated. 


If the authentication is successful, the authentication 
server then attempts to authenticate itself to the peer by 
use of the Confirm TLV (see below). If the authentication 
fails, the EAP server MAY send another EAP-Request of type 
POTP-X containing an OTP TLV to the peer, or it MAY send an 
EAP-Failure message (in both cases, possibly preceded by an 
EAP-Request of type Notification). 


4.11.4. NAK TLV 


Presence of this TLV indicates that the peer did not support a 
received TLV with the M bit set. This TLV may occur 0, 1, or more 
times in an EAP-Response of type POTP-X. Each occurrence flags the 
non-support of a particular received TLV. 


The NAK TLV MUST be supported by all peers and all EAP servers 
conforming to this specification and MUST NOT be responded to with a 
NAK TLV. Receipt of a NAK TLV by an EAP server MAY cause an 
authentication to fail, and the EAP server to send an EAP-Failure 
message to the peer. 
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Note: The definition of the NAK TLV herein matches the definition 
made in [17], and has the same type number. Field descriptions are 
copied from that document, with some minor modifications. 


0 1 2 3 
Oud. ¿2354 DO fh 8 9000 2:39 4.091,06: 18:19:20: 1, <2) 3 429,06: 7. 8:09:00: 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|M|R| TLV Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Vendor-Id | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| NAK-Type | TLVs 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


M 
1 - Mandatory TLV 

R 
Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 

TLV Type 
4 

Length 
6 + cumulative total length of embedded TLVs 

Vendor-Id 
The Vendor-Id field is 4 octets, and contains the Vendor-Id of the 
TLV that was not supported. The high-order octet is 0 and the 
low-order 3 octets are the Structure of Management Information 
(SMI) Network Management Private Enterprise Code of the Vendor in 
network byte order. The Vendor-Id field MUST be zero for TLVs 
that are not Vendor-Specific TLVs. For Vendor-Specific TLVs, the 
Vendor-ID MUST be set to the SMI code. 

NAK-Type 


The type of the unsupported TLV. The TLV MUST have been included in 
the most recently received EAP message. 
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TLVs 


This field contains a list of TLVs, each of which MUST NOT have the 
mandatory bit set. These optional TLVs can be used in the future to 
communicate why the offending TLV was determined to be unsupported. 


4.11.5. New PIN TLV 


In an EAP-Request, the New PIN TLV is used to request a new user PIN 
from the peer. The EAP server MAY provide a new PIN, as described 
below. In an EAP-Response, the New PIN TLV carries a chosen new user 
PIN. This TLV may be used by an EAP server when policy dictates that 
the peer (user) needs to change a PIN associated with the OTP Token. 


This TLV type SHOULD be supported by peers and EAP servers conforming 
to this specification. The New PIN TLV MUST NOT be sent by an EAP 
server unless the peer has been authenticated. If the peer was 
authenticated in protected mode, then the New PIN TLV MUST NOT be 
present in an EAP-Request until after the exchange of the Confirm TLV 
(i.e., until after mutual authentication has occurred and keys are in 
place to protect the TLV). The New PIN TLV MUST be sent by a peer if 
and only if the EAP-Request that triggered the response contained a 
New PIN TLV, it was valid for the EAP server to send such a TLV in 
that request, and the TLV is supported by the peer. 


0 1 2 3 
0.1.2 3 405 62 B90) L 2 3). 45 6 FB 9. OL .2.3 4 6-89-01 
dd AO A A O O O O AO A A O O O A O O O A O O AO O O o o + o + 


|M|R| TLV Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Reserved |Q|A| PIN Length | PIN 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Min. PIN Length|Max. PIN Length| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


M 
1 - Mandatory TLV 

R 
Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 

TLV Type 


5 
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Length 


2 + length of the PIN field (as specified in the PIN Length field) 
+ (0, 1, or 2) 


Note: The final term above is 

- 0 if none of the optional Min. / Max. PIN Length fields is 
present in the TLV, 

- 1 if only the Min. PIN Length field is present in the TLV, 

- 2 if both of these optional fields are present in the TLV. 


Reserved 
Reserved for future use. All six bits SHALL be set to zero for 


this version. Recipients SHALL ignore these bits for this version 
of EAP-POTP. 


Q 
The Q bit, when set in an EAP-Request, indicates that an 
accompanying PIN is required, i.e., the peer (user) is not free to 
choose another PIN. When the Q bit is set, there MUST be an 
accompanying PIN and the provided PIN MUST be used in subsequent 
OTP generations. A peer SHALL respond with an empty POTP-X EAP- 
Response message if the Q bit is set but there is not any 
accompanying PIN. When the Q bit is not set, any provided PIN is 
suggested only, and the peer is free to choose another PIN, 
subject to local policy. 
The Q bit carries no meaning, and SHALL be set to zero, in an EAP- 
Response. 

A 
This bit allows methods that distinguish between two different PIN 
types (e.g., decimal vs. alphanumeric) to designate whether the 
augmented set is to be used (when set) or not (when not set). The 
A bit carries no meaning, and SHALL be set to zero, in an EAP- 
Response. 

PIN Length 


This field contains an unsigned integer representing the length of 
the provided PIN (this implies that the maximum length of a PIN 
will be 255 octets). 
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PIN 


In an EAP-Request, subject to the setting of the Q bit, the PIN 
field MAY be empty. If empty, the peer (user) will need to choose 
a PIN subject to local and (any) provided policy. When the PIN 
field is not empty, it MUST consist of UTF-8 encoded printable 
characters without a terminating NULL character. 


In an EAP-Response, the PIN value SHALL consist of a UTF-8 encoded 
string of printable characters without a terminating NULL 
character. 


The peer accepts a PIN suggested by the EAP server by replying 
with the same PIN, but MAY replace it with another one, depending 
on the server's setting of the Q bit. The length of the PIN is 
application-dependent, as are any other requirements for the PIN, 
e.g., allowed characters. The peer MUST be prepared to receive a 
repeated request for a new PIN, as described above, if the EAP 
server, for some reason does not accept the received PIN. Such a 
request MAY be preceded by an EAP-Request of type Notification (2) 
providing information to the user about the reason for the 
rejection. Mechanisms for transferring knowledge about PIN 
requirements from the EAP server to the peer (beyond those 
specified for this TLV, such as maximal and minimal PIN length) 
are outside the scope of this document. However, some information 
MAY be provided in notification messages transferred from the EAP 
server to the peer, as per above. 


Min. PIN Length 


This field MAY be present in an EAP-Request. This field MUST NOT 
be present in an EAP-Response. It SHALL be interpreted as an 
unsigned integer in network byte order representing the minimum 
length allowed for a new PIN. 


Max. PIN Length 


This field MUST NOT be present in an EAP-Request unless the Min. 
PIN Length field is present, in which case it MAY be present. The 
field MUST NOT be present in an EAP-Response. It SHALL be 
interpreted as an unsigned integer in network byte order 
representing the maximum length allowed for a new PIN. The value 
of this field, when present, MUST be equal to, or larger than, the 
value of the Min. PIN Length field. 
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4.11.6. Confirm TLV 


Presence of this TLV in a request indicates that the EAP server has 
successfully authenticated the peer and now attempts to authenticate 
itself to the peer. Presence of this TLV in a response indicates 
that the peer successfully authenticated the EAP server, and that 
calculated keys (K_MAC, K_ENC, MSK, EMSK, and SRK) now become 
available for use. 


The Confirm TLV MUST NOT appear together with any other TLV in an 
EAP-Request message of type POTP-X and MUST NOT be sent unless the 
peer has been authenticated through an OTP TLV with the P bit set or 
through a Resume TLV for which the underlying session was established 
in protected mode. The Confirm TLV MUST be present in an EAP- 
Response if and only if the request that triggered the response 
contained a Confirm TLV, it was legal for it to do so, and the 
Confirm TLV authenticated the EAP server to the peer. If the peer 
was not able to authenticate the server, then it MUST send an empty 
(i.e., no TLVs present) EAP-Response of type POTP-X. 


An EAP server MUST send an EAP-Success message after receiving an 
EAP-Response of type POTP-X containing a valid Confirm TLV, sent in 
response to an EAP-Request containing a Confirm TLV where the C bit 
was not set. A peer MUST NOT accept an EAP-Success message when it 
has sent an OTP TLV with the P bit set unless it has received an 
acceptable Confirm TLV from the EAP server. 


This TLV type MUST be supported by all peers and EAP servers 
conforming to this specification and MUST NOT be responded to with a 
NAK TLV. 


0 1 2 3 
OP. 26349167) 859-0. 1 2:34 25 6. 7289) OL 23 4.3 62 T 18-90. 1 
+-+-+-+-+-+-+-+-+-+-+-+-+ tata ta ++ ++ +++ + +++ + +++ ++ 
|M|R| TLV Type | Length | 
dh + Ph q tata to ta tata tata ta ++ + + +++ ++ +++ +++ ++ 
| Reserved |c] Authentication Data ... (16 octets) 
dh + Ph dd tata titan + + + + ta ++ + + +++ ++ +++ +++ ++ 
| Pepper Identifier 
dh + hh q tata titan + + d+ + ta ++ + + +++ ++ +++ +++ += 
| EV dah 
dh + hh q hd + + + + + ++ ++ +++ + +++ ++ +++ 
| Encrypted Pepper ... (16 octets) 
dh + Ph q hd + + + + + + ++ ++ +++ ++ +++ +++ += 


M 


1 - Mandatory TLV 
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R 
Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 

TLV Type 
6 

Length 
17 or 37 + length of IV in requests, 1 in responses. 

Reserved 
Reserved for future use. These 7 bits SHALL be set to zero (0) 
for this version. Recipients SHALL ignore these bits for this 
version of EAP-POTP. 

C 


The C bit, when set in an EAP-Request, indicates that the EAP 
server intends to send more EAP-Requests of type POTP-X in this 
session, after receipt of a Confirm TLV from the peer. 


The C bit carries no meaning in EAP-Responses, and MUST NOT be set 
within them. 


Note: An EAP-Response containing a Confirm TLV, sent in response 
to an EAP-Request containing a Confirm TLV that did not have the C 
bit set, MUST be followed by an EAP-Success message from the EAP 
server concluding the handshake. However, when the C bit was set 
in an EAP-Request, the EAP server MAY send another EAP-Request 
(containing, for example, a New PIN TLV wrapped in a Protected 
TLV) rather than an EAP-Success message. Therefore, peers MUST 
NOT assume that the only EAP message following an EAP-Response of 
type POTP-X containing a Confirm TLV is EAP-Success. The C bit 
gives EAP servers a way to indicate their intent to follow the 
Confirm TLV with more requests, and allows the peer’s state 
machine to adapt to this. 


Authentication Data 
EAP-Request: 


In a request, this field consists of the first 16 octets of 
(see also Section 4.11.3): 
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mac_a = MAC(K_MAC’, msg_hash(trig_msg) ) 
where 
MAC is the negotiated MAC algorithm, 


"K_MAC’" has been calculated as described in Section 4.11.3 or 
(in the case of session resumption) Section 4.11.8, and 


"msg_hash" is the message hash algorithm defined in Section 
4.9, and "trig_msg" the latest EAP-Response of type POTP-X 
received from the peer (the one which triggered this request). 


Given a saved or recomputed value for K_MAC, the peer 
authenticates the EAP server by computing 


mac’’ = MAC(K_MAC, msg_hash(trig_msg')) 


where "msg_hash(trig_msg’)" is the peer's hash of the EAP- 
Response message that it sent to the server (and that the 
server calculated its message hash on). If the first 16 octets 
of mac'” matches the first 16 octets in the Authentication Data 
field of the EAP-Request in question, then the EAP server is 
authenticated. 


EAP-Response: 


Not used in this version, and SHALL NOT be present in EAP- 
Responses. 


Pepper Identifier 
In an EAP-Request, the truncated MAC MAY optionally be followed by 


an encrypted pepper and its identifier. This initial, 4-octet 
field identifies a pepper generated by the server. 


For this version of EAP-POTP, this field SHALL NOT be present in 
EAP-Responses. 


IV (Initialization Vector) 


An initialization vector for the encryption. The length of the 
vector is dependent on the negotiated encryption algorithm. For 
example, for AES-CBC, it SHALL be 16 octets. The IV is only 
present if a pepper is present, and the negotiated encryption 
algorithm makes use of an IV. This field SHALL NOT be present in 
EAP-Response messages for this version of EAP-POTP. 
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Encrypted Pepper 


When present in an EAP-Request, this will be a uniformly 
distributed and randomly chosen 16-octet pepper generated by the 
EAP server and encrypted with the negotiated encryption algorithm, 
using K_ENC as the encryption key and possibly (depending on the 
encryption algorithm) using an IV (stored in the IV field). This 
field MUST be present if and only if the Pepper Identifier field 
is present. 


EAP servers are RECOMMENDED to include a freshly generated 
encrypted pepper (and a corresponding Pepper Identifier) in every 
Confirm TLV. 


This field SHALL NOT be present in EAP-Response messages for this 
version of EAP-POTP. 


When a new pepper is generated by the server and transferred in 
encrypted form to the peer, then this new pepper value will be stored 
in the EAP server upon receipt of the Confirm TLV from the peer, and 
SHOULD be stored with its identifier and associated with the EAP 
server and the current user in the peer upon receipt of the EAP- 
Success message. If the peer already had a pepper stored for the EAP 
server, it SHALL replace it with the newly received one. 


4.11.7. Vendor-Specific TLV 


The Vendor-Specific TLV is available to allow vendors to support 
their own extended attributes not suitable for general usage. A 
Vendor-Specific TLV can contain one or more inner TLVs, referred to 
as Vendor TLVs. The TLV-type of a Vendor TLV will be defined by the 
vendor. All the Vendor TLVs inside a single Vendor-Specific TLV 
SHALL belong to the same vendor. 


This TLV type MAY be sent by EAP servers, as well as by peers, and 
MUST be supported by all entities conforming to this specification. 
Conforming implementations may not support specific Vendor TLVs 
inside a Vendor-Specific TLV, however. They MAY, in this case, 
respond to the Vendor TLVs with a NAK TLV containing the appropriate 
Vendor-ID and Vendor TLV type. 


The presence of a Vendor-Specific TLV in an EAP-Request or EAP- 
Response of type POTP-X MUST NOT violate any existing rules for 
coexistence of TLVs in such requests or responses. If it does, then 
it will result in an EAP-Failure (when the peer made the violation) 
or an empty EAP-POTP response (when the EAP-server made the 
violation). It is left to the definition of specific Vendor-Specific 
TLVs to further constrain when they are allowed to appear. In 
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particular, EAP-POTP implementations may have policies that 
completely disallow use of the Vendor-Specific TLV before protected 
mode mutual authentication has occurred (since the Protected TLV, 
Section 4.11.15, then can be used to protect all TLVs). 


Note: This TLV type has the same definition and TLV type number as 
the Vendor-Specific TLV in [17], and the description of it is largely 
borrowed from that document. 


0 1 2 3 
0123456789012345678901234567800m1 
+ -+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| 

+ HA AA A o o 
| Vendor-Id | 
$oFF Foti A A HHHH 
| Vendor TLVs 

foFoFFi A A pepo p HHHH 


1 - Mandatory TLV 


Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 

TLV Type 
7 

Length 
4 + cumulative total length of inner Vendor TLVs 

Vendor-ID 
The Vendor-Id field is 4 octets. The high-order octet SHALL be 
set to 0, and the low-order 3 octets SHALL be set to the SMI 


Network Management Private Enterprise Code (see [18]) of the 
Vendor in network byte order. 
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Vendor TLVs 


This field shall contain vendor-specific TLVs, in a format defined 
by the vendor. To avoid fragmentation (i.e., EAP messages longer 
than the minimum EAP MTU size), the field SHOULD NOT be longer 
than 256 octets. 


To ensure interoperability when an EAP entity (peer or server) from 
vendor A sends a vendor-specific TLV that is not understood by the 
recipient EAP entity from vendor B, the vendor A entity SHALL, upon 
receipt of the NAK TLV from the recipient, refrain from usage of the 
vendor-specific TLV in question for the rest of the handshake, and 
MUST NOT fail the session due to the receipt of the NAK TLV for the 
Vendor TLV (i.e., it SHALL continue as if the vendor-specific TLV had 
not been sent). Additionally, all implementations conformant with 
this document SHOULD allow use of vendor-specific extensions to be 
turned off via configuration. 


4.11.8. Resume TLV 


The Resume TLV MAY be sent by a peer to an authentication server to 
attempt session resumption. 


This TLV type MUST only be sent in response to an EAP-Request of type 
POTP-X containing a Server-Info TLV allowing session resumption. The 
Resume TLV MUST be supported by all EAP servers that send a Server- 
Info TLV allowing session resumption. 


0 1 2 3 

01234567890123456789012345678090U1 

a E E E tat 

M|R| TLV Type | Length | 

SPF atta tata t ata t ata tata tata tata tata tata tata tata tata tata A tat 

Reserved | Session Identifier 

a tot ta ta tata tata tata tata tata tata tata tata tata E 
Session Identifier (continued) | 

FoF RFR Fatt ata tat E E E O 

|Sess.Id (cont.) | Authentication Data 

Pat rt tata tar tata tata tata tata ta tata t tata tata tata tatatatatata tat 

| Authentication Data (cont.) 

a atta tata tata t tata tata tata tata tata tata tata E E tat 


+ 
| 
+ 
| 
+ 
| 


M 


0 - Non-mandatory TLV 
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R 
Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 

TLV Type 
8 

Length 
45 

Reserved 
Reserved for future use. This octet SHALL be set to zero (0) for 


this version. Recipients SHALL ignore this octet for this version 
of EAP-POTP. 


Session Identifier 


An 8-octet identifier for the session the peer is trying to 
resume. 


Authentication Data 


Upon receipt of the Server-Info TLV, and if the N bit is not set, 
the peer searches for any stored sessions associated with the 
server identified by the Server Name field. If a stored session 
is found, the peer generates a random, 16-octet nonce, "c_nonce", 
and calculates: 


K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2 (base_key, c_nonce 
s_nonce, iteration_count, key_length) 


where 

a denotes concatenation, 

"base_key" is either the current SRK for the session (if the 
session was created in protected mode) or the OTP used when the 
session was created (if the session was created in basic mode), 


"c_nonce" is the generated 16-octet nonce, 


"s nonce" is the server nonce from the Server-Info TLV, 
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"iteration_count" is the iteration count as determined by local 
policy, and 


"key_length" is the combined length of the desired key material, 
in octets. When the default algorithms are used, key_length is 
176. 


The iteration count need only be 1 (one) when resuming a session 
established in protected mode, but MUST be chosen to provide a 
suitable level of protection when resuming a session established 
in basic mode (see also Section 4.11.3). 


Note: Session resumption for basic mode MUST only be carried out 
in a server-authenticated and protected tunnel that also provides 
a cryptographic binding for inner EAP methods. 


The peer then calculates: 

mac = MAC(K_MAC, msg_hash(resume_req) ) 

where 

"MAC" is the negotiated MAC algorithm, and 

"msg_hash(resume_req) is the message hash algorithm defined in 
Section 4.9 applied on resume_req, the EAP server’s EAP-Request of 


type POTP-X containing the Server-Info TLV that allowed session 
resumption. 


The peer then places the first 16 octets of the MAC value, 
followed by the c_nonce value, followed by the iteration count 
value (as a 4-byte unsigned integer in network byte order), in the 
Authentication Data field. As an example, when c_nonce = 
0x2b3b1b12babdebebfb43bd7bdfbeb8df and iteration_count = 1, the 
Authentication Data field will be populated with (in hex): 


< 16 octets of mac > | 2b3b1b12babdebebfb43bd7bdfbeb8df£ | 00000001 


The server authenticates the peer by performing the corresponding 


calculations. If the authentication is successful, the server 
MUST send an EAP-Request of type POTP-X containing a Confirm TLV 
to the peer. If the authentication fails, the server MUST either 


send an EAP-Request of type POTP-X containing an OTP TLV and a 
Server-Info TLV, where the Server-Info TLV indicates that session 
resumption is not possible, or send an EAP-Failure. 
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When resuming in basic mode, all calculated keys SHALL be 
discarded after the MAC has been calculated and verified. When 
resuming in protected mode, the new SRK will replace the stored 
SRK, and the new MSK and EMSK will be exported upon successful 
completion of the method. 


4.11.9. User Identifier TLV 


The User Identifier TLV carries an identifier, typically the 
username, for the holder of the OTP token used to generate the OTP. 


At least one of the User Identifier TLV and the Token Key Identifier 
TLV SHOULD be present in the session's first EAP-Response of type 
POTP-X that also carries an OTP TLV unless a suitable identity has 
been provided in a preceding EAP-Response of type Identity (1) or is 
determined by some other means (see [1], Section 2). Use of the User 
Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED 
even when an EAP-Response of type Identity (1) has been sent. If a 
peer sends both a User Identifier TLV and a Token Key Identifier TLV, 
then the EAP server SHALL interpret the Token Key Identifier TLV as 
specifying a particular token key for the given user. The EAP server 
MUST respond with an EAP-Failure if it cannot find a token key for 
the provided user. 


This TLV type is sent by peers and MUST be supported by all EAP 
servers conforming to this specification. The User Identifier TLV 
MUST NOT be present in a response that does not also carry an OTP 
TLV. 


0 1 2 3 
OL 2 3 AS Or 089. Or de 23. A 0067 8: 97:00 1.23 473: 06: 7/8 9:,0: 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|M|R| TLV Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| User Identifier 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


M 


1 - Mandatory TLV 


Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 


Nystroem Informational [Page 46] 


RFC 4793 EAP-POTP February 2007 


TLV Type 

9 
Length 

Length of User Identifier, >= 1 
User Identifier 


The value SHALL be an UTF-8 encoded string representing the holder 
of the token (MUST NOT be NULL-terminated). The string MUST be 
less than 128 octets in length. 


4.11.10. Token Key Identifier TLV 


The Token Key Identifier TLV carries an identifier for the token key 
used to generate the OTP. 


At least one of the User Identifier TLV and the Token Key Identifier 
TLV SHOULD be present in the session's first EAP-Response of type 
POTP-X, which also carries the OTP TLV unless a suitable identity has 
been provided in a preceding EAP-Response of type Identity (1) or is 
determined by some other means (see [1], Section 2). Use of the User 
Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED 
even when an EAP-Response of type Identity (1) has been sent. If a 
peer sends both a User Identifier TLV and a Token Key Identifier TLV, 
then the EAP server SHALL interpret the Token Key Identifier TLV as 
specifying a particular token key for the given user. The EAP server 
MUST respond with an EAP-Failure if it cannot find a token key 
corresponding to the provided token key identifier. 


This TLV type is sent by peers and MUST be supported by all EAP 
servers conforming to this specification. The Token Key Identifier 
TLV MUST NOT be present in a response that does not also carry an OTP 
TLV. 


0 Al 2 3 
Od, 2-34, 5:%6, Y 89 00112034 10-617 80901. 0203 45:06 Y. 8:90 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|M|R| TLV Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Token Key Identifier 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


M 


1 - Mandatory TLV 
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R 
Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 

TLV Type 
10 

Length 


Length of Token Key Identifier, >= 1 
Token Key Identifier 


An identifier for the OTP token key used to generate the OTP. The 
field MUST be less than 128 octets in length. 


4.11.11. Time Stamp TLV 


The Time Stamp TLV MAY be sent by peers to simplify authentications. 
When present, it carries the time as reported by the OTP Token. 


An EAP server conformant with this specification SHOULD support 
(i.e., recognize) this TLV, but need not be able to process or act on 
it. An EAP server that does not support this TLV, but receives an 
EAP-Response with the TLV present, MAY ignore the value. The Time 
Stamp TLV MUST NOT be present in any EAP-Responses of type POTP-X 
other than those that also carries an OTP TLV. 


0 1 2 3 
OL. 2v3) A S 67) 8° 90D, 23:45 06:18 G0 1: 23-439 06-78-90. 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|M|R| TLV Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Time Stamp 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


M 


0 - Non-mandatory TLV 


Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 
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TLV Type 

11 
Length 

Length of Time Stamp field, >= 20 (depending on precision) 
Time Stamp 


The time, as reported by the OTP token, at which the OTP used for 
the accompanying OTP TLV was calculated. The field SHALL contain 
a UTF-8 encoded value of the XML simple type "dateTime", with time 
zone information and precision down to at least seconds, e.g., 
"2004-06-16T15:20:022". 


4.11.12. Counter TLV 


The Counter TLV MAY be sent by peers to simplify authentications. 
When present, it carries the token counter value, as reported by the 
OTP Token. 


An EAP server conformant with this specification SHOULD support 
(i.e., recognize) this TLV, but need not be able to process or act on 
it. An EAP server that does not support this TLV, but receives an 
EAP-Response with the TLV present, MAY ignore the value. The Counter 
TLV MUST NOT be present in any EAP-Responses of type POTP-X other 
than those that also carries an OTP TLV. 


0 1 2 3 
OLEA O 8 OY Or AL: 23 4 So 6 7 8: 91:01 1.2037 AR Ds 06) 718 OO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|M|R| TLV Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Counter 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


M 


0 - Non-mandatory TLV 


Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 
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TLV Type 

12 
Length 

Length of Counter field, >= 1 (depending on precision) 
Counter 


The counter value, as reported by the OTP token, at which the OTP 
used for the accompanying OTP TLV was calculated. The counter 
value SHALL be represented as an unsigned integer in network-byte 
order, e.g., a counter value of 1030 may be sent as the 2 octets 
(in hex) 04 06. 


4.11.13. Challenge TLV 


The Challenge TLV carries the challenge used by the token to 
calculate the OTP, as reported by the token to the peer. The 
Challenge TLV MUST be sent by a peer if and only if the challenge 
otherwise would be unknown to the EAP server (e.g., the token or peer 
modified a received challenge or generated its own challenge). 


An EAP server conformant with this specification SHOULD support 
(i.e., recognize) this TLV, but need not be able to process or act on 
it. An EAP server that does not support this TLV, but receives an 
EAP-Response with the TLV present, MAY ignore the value. The 
Challenge TLV MUST NOT be present in any EAP-Responses of type POTP-X 
other than those that also carry an OTP TLV. 


0 1 2 3 
012345678901 23456789012345678090u1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|M|R| TLV Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Challenge 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


M 


0 - Non-mandatory TLV 


Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 
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TLV Type 

16 
Length 

Length of Challenge field, >= 1 
Challenge 


The challenge value that was used to calculate the OTP used for 
the accompanying OTP TLV. 


4.11.14. Keep-Alive TLV 
The Keep-Alive is used to avoid EAP-POTP timeouts. 


The Keep-Alive TLV MAY be sent by a peer to avoid timeouts when the 
peer has received an EAP-Request containing an OTP TLV or a New PIN 
TLV and is waiting for a response from the user. 


An EAP-Request containing a Keep-Alive TLV MUST be sent by an EAP 
server when the server receives an EAP-Response containing a Keep- 
Alive TLV, and the server has an outstanding request that did not 
contain a Keep-Alive TLV. In this situation, the server does not 
need to re-transmit its latest outstanding request, but, due to the 


synchronous nature of EAP, it needs to send another request. Re- 
transmission of the latest outstanding request could be confusing for 
the peer since the request would get a new Identifier value. The 


Keep-Alive TLV MAY also be sent by an EAP server when the server 
detects that its processing time will exceed some locally configured 
threshold and may cause a network timeout. In this case, the peer 
MUST respond with an EAP-Response containing a Keep-Alive TLV. 


This TLV type MUST be supported by all peers and all EAP servers 
conforming to this specification and MUST NOT be responded to with a 
NAK TLV. The Keep-Alive TLV MUST NOT be sent in any other situations 
than the ones described above. The Keep-Alive TLV MUST NOT be sent 
together with any other TLVs defined herein. Implementations SHOULD 
also follow recommendations made in Section 4.3 of [1]. 


0 1 2 3 
Qui: 2-34 506: 8 9001.23 49.09.06: 18:90: 1, 2) 3s 4 9:06: FB 9: 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|M|R| TLV Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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1 - Mandatory TLV 


R 


Reserved for future use. This bit SHALL be set to zero (0) for this 
version. Recipients SHALL ignore this bit for this version of EAP- 
POTP. 


TLV Type 
13 
Length 
0 
4.11.15. Protected TLV 


The Protected TLV SHALL be used to encrypt individual or multiple 
TLVs after successful exchange of the Confirm TLV (i.e., as soon as 
calculated keys have been confirmed). The Protected TLV therefore 
wraps "ordinary" TLVs. 


This TLV type may be sent by EAP servers as well as by peers and MUST 
be supported by all peers conforming to this specification. It 
SHOULD be supported by all EAP servers conforming to this 
specification (it need not be supported if a server never will have a 
need to continue a POTP-X conversation after exchange of the Confirm 
TLV). 


0 1 2 3 
Od 2 TE be INE B90 IS E 5 56> EE E VI ES TE O E OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| TLV Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Message Authentication Code ... (16 octets) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
IV aie 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Encrypted TLVs ... 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Iz I 
+—+ 
1D I 


+— +—+—+—+ 


zZ 


1 - Mandatory TLV 
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Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 


TLV Type 


14 


Length 


>32 


Message Authentication Code (MAC) 


IV 


This field integrity-protects the TLV. The MAC SHALL be 
calculated over the IV and the Encrypted TLVs field in the 
following manner: 


mac = MAC(K_MAC, iv | encrypted_tlvs) 
where 


MAC is the negotiated MAC algorithm, "iv" is the IV field's value, 
and "encrypted_tlvs" is the value of the Encrypted TLVs field. 

The first 16 octets of the MAC is placed in the Message 
Authentication Code field. 


Recipients MUST verify the MAC. If the verification fails, the 
conversation SHALL be terminated (i.e., peers send an empty POTP-X 
EAP-Response message, and EAP servers send an EAP-Failure message 
possibly preceded by an EAP-Request of type Notification). 


An initialization vector for the encryption; see below. The 
length of the vector is dependent on the negotiated encryption 
algorithm, e.g., for AES-CBC, it shall be 16 octets. For some 
encryption algorithms, there may not be any initialization vector. 
An IV, when present, shall be randomly chosen and non-predictable. 


Encrypted TLVs 


This field SHALL contain one or more encrypted POTP-X TLVs. The 
encryption algorithm SHALL be as negotiated; use K_ENC as the 
encryption key, and use the IV field as the initialization vector 
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(when applicable), to encrypt the concatenation of all the TLVs to 
be protected. 


4.11.16. Crypto Algorithm TLV 


The Crypto Algorithm TLV allows for negotiation of cryptographic 
algorithms. Cryptographic Algorithm negotiation is described in 
detail in Section 4.3. 


This TLV MUST be present in the initial EAP-Request of type POTP-X 
that also carries an OTP TLV indicating protected mode, assuming the 
EAP server wants to negotiate use of any other algorithms than the 
default ones. It MAY also be present in an EAP-Request of type 
POTP-X that carries an OTP TLV that is sent as a result of a failed 
session resumption (in this case, the peer has not yet responded to 
this TLV), or when the Crypto Algorithm TLV was part of the initial 
message from the EAP server, and the client negotiated another EAP- 
POTP version than the highest one supported by the EAP server. The 
Crypto Algorithm TLV MUST NOT be present in any other EAP-Requests. 
Further, the Crypto Algorithm TLV MUST NOT be present in an EAP- 
Response of type POTP-X unless the preceding EAP-Request also 
contained it, and it was legal for it to do so. This TLV MUST be 
supported by all peers and all EAP servers conforming to this 
specification and MUST NOT be responded to with a NAK TLV. 


0 1 2 3 
0042 8: ARS. 60 TBO OR 1" BP Be AS 1965 8 90 OF 23 Ae, 6 Ye 8:90:41 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|M|R| TLV Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Reserved |Hash Alg.Length| Hash Algorithms ' 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Encr.Alg.Length] Encryption Algorithms 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| MAC Alg. Length | MAC Algorithms 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


M 


1 - Mandatory TLV 


Reserved for future use. This bit SHALL be set to zero (0) for 
this version. Recipients SHALL ignore this bit for this version 
of EAP-POTP. 
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TLV Type 
15 
Length 


>=4 (at least one class of algorithms and one algorithm for that 
class needs to be present) 


Reserved 
Reserved for future use. This octet MUST be set to zero for this 
version. Recipients SHALL ignore this octet for this version of 
EAP-POTP. 


Hash Alg. Length 
The length of the Hash Algorithms field in octets. 
Hash Algorithms 


Each octet pair of this field represents a hash algorithm as 
follows. An EAP server MAY supply several suggestions for hash 
algorithms. Each algorithm MUST appear only once. The algorithms 
SHALL be supplied in order of priority. Peers MUST supply, at 
most, one algorithm (if none is present, the default applies). 

The defined values are: 


Value 
Octet 1 Octet 2 Hash algorithm 


0x00 0x00 Reserved 

0x00 0x01 SHA-1 

0x00 0x02 SHA-224 

0x00 0x03 SHA-256 (default) 

0x00 0x04 SHA-384 

0x00 0x05 SHA-512 

0x80 - Vendor-specific (or experimental) 


As indicated, values 0x8000 and higher are for proprietary 
vendor-specific algorithms. Values in the range 0x0006 - Ox7fff 
are to be assigned through IANA; see Section 7. 


Encr Alg. Length 


The length of the Encryption Algorithms field in octets. 
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Encryption Algorithms 


Each octet pair of this field represents an encryption algorithm 
as follows. An EAP server MAY supply several suggestions for 
encryption algorithms. Each algorithm MUST appear only once. The 
algorithms SHALL be supplied in order of priority. Peers MUST 
supply, at most, one algorithm (if none is present, the default 
applies). The defined values are: 


Value 
Octet 1 Octet 2 Encryption algorithm 


0x00 0x00 Reserved 

0x00 0x01 AES-CBC (default) with 128-bit keys and 16-octet IVs 
0x00 0x02 3DES-CBC with 112-bit keys and 8-octet IVs 

0x80 = Vendor-specific 


As indicated, values 0x8000 and higher are for vendor-specific 
proprietary algorithms. Values in the range 0x0003 - Ox7fff are 
to be assigned through IANA; see Section 7. 


MAC Alg. Length 
The length of the MAC Algorithms field in octets. 
MAC Algorithms 


Each octet pair of this field represents a MAC algorithm as 
follows. An EAP server MAY supply several suggestions for MAC 
algorithms. Each algorithm MUST appear only once. The algorithms 
SHALL be supplied in order of priority. Peers MUST supply, at 
most, one algorithm (if none is present, the default applies). 

The defined values are: 


Value 
Octet 1 Octet 2 MAC algorithm 


0x00 0x00 Reserved 
0x00 0x01 HMAC (default) 
0x80 = Vendor-specific 


As indicated, values 0x8000 and higher are for vendor-specific 
proprietary algorithms. Values in the range 0x0002 - Ox7fff are 
to be assigned through IANA; see Section 7. 


When HMAC is negotiated, the hash algorithm used for HMAC SHALL be 
the negotiated hash algorithm. 
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3% 


6. 


February 2007 


EAP Key Management Framework Considerations 


In line with recommendations made in [16], 


EAP-POTP defines the 


following identifiers to be associated with generated key material: 


Peer-ID: The combined contents of the User Identifier TLV and the 


Token Key Identifier TLV. 


Server-ID: The contents of the Server Identifier field of the 


Server-Info TLV. 


Method-ID: The identifier of the established session (i.e., the 
contents of the Session Identifier field of the Server-Info TLV 


that defined the session). 


Security Considerations 


1. Security Claims 


In conformance with RFC 3748 [1], the following security claims are 


made for the EAP-POTP method: 


Authentication mechanism: Generic OTP 


Ciphersuite negotiation: Yes (No in basic variant) 

Mutual authentication: Yes (No in basic variant) 

Integrity protection: Yes (No in basic variant) 

Replay protection: Yes (see below) 

Confidentiality: Only in the OTP protection variant, and 


then only OTP values and any information 
sent after exchange of the Confirm TLV 

Key derivation: Yes (No in basic variant) 

Key strength: Depends on size of OTP value, strength of 
underlying shared secret, strength and 
characteristics of OTP algorithm, pepper 
length, iteration count, and whether the 
method is used within a tunnel such as 
PEAPv2. For some illustrative examples, 
and a further discussion of this, see 


Appendix D. 
Dictionary attack prot.: N/A (Human-selected passwords not used) 
Fast reconnect: Yes 
Crypt. binding: N/A (EAP-POTP is not a tunnel method) 
Session independence: Yes 
Fragmentation: N/A (Packets shall not exceed MTU of 1020) 
Channel binding: Yes (No in basic variant) 
Acknowledged S/F: Yes 
State Synchronization: Yes (No in basic variant) 
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6.2. Passive and Active Attacks 


The basic variant (i.e., when the protection of OTPs and mutual 
authentication is not used) of this EAP method does not provide 
session privacy, session integrity, server authentication, or 
protection from active attacks. In particular, man-in-the-middle 
attacks, where an attacker acts as an authenticator in order to 
acquire a valid OTP, are possible. 


Similarly, the basic variant of this EAP method does not protect 
against session hijacking taking place after authentication. Nor 
does it, in itself, protect against replay attacks, where the 
attacker gains access by replaying a previous valid request, but see 
also the next subsection. When PIN codes are transmitted, they are 
sent without protection and are also subject to replay attacks. 


In order to protect against these attacks, the peer MUST only use the 
basic variant of this method over a server-authenticated and 
confidentiality-protected connection. This can be achieved via use 
of, PEAPv2 [17], for example. 


When the OTP protection variant is used, however, the EAP method 
provides privacy for OTPs and new PINs, negotiation of cryptographic 
algorithms, mutual authentication, and protection against replay 
attacks and protocol version downgrades. It also provides protection 
against man-in-the-middle attacks, not due to the infeasibility for a 
man-in-the-middle to solve for a valid OTP given an OTP TLV, but due 
to the computational expense of finding the OTP in the limited time 
period during which it is valid (this is mainly true for tokens, 
including the current time in their OTP calculations, or when a sent 
challenge has a certain lifetime). It should be noted, however, that 
a retrieved OTP, even if "old" and invalid, still may divulge some 
information about the user’s PIN. Clearly, this is also true for the 
basic variant. Implementations of this EAP method, where user PINs 
are sent with OTPs, are therefore RECOMMENDED to ensure regular user 
PIN changes, regardless of whether the protected variant or the basic 
variant is employed. 


It should also be noted that, while it is possible for a rogue access 
point, e.g., to clone MAC addresses, and hence mount a man-in-the- 
middle attack, such an access point will not be able to calculate the 
session keys MSK and EMSK. This demonstrates the importance of using 
the derived key material properly to protect a subsequent session. 


Protected mode protects against version downgrade attacks due to the 
HMAC both parties transmit in this mode. As described, each party 

calculates the HMAC on sent and received EAP-POTP handshake messages. 
If an attacker were to modify a Version TLV, this would be reflected 
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in a difference between the calculated MACs (since the recipient of 
the Version TLV received a different value than the sender sent). 
Unless the attacker knows K_MAC, he cannot calculate the correct MAC, 
and hence the difference will be detected. 


The OTP protection variant also protects against session hijacking, 
if the derived key material is used (directly or indirectly) to 
protect a subsequent session. For these reasons, use of the OTP 
protection variant is RECOMMENDED. 


However, it should be noted that not even the OTP protection variant 
provides privacy for user names and/or token key identifiers. EAP- 

POTP MUST be used within a secure tunnel such as the one provided by 
PEAPv2 [17] if privacy for these parameters is required. 


When resuming sessions created in the basic variant (which MUST only 
take place within a protected tunnel), the peer is authenticated by 
demonstrating knowledge of not just a valid session identifier, but 
also the OTP used when the session was created. Server nonces 
prevent replay attacks, but there still remains some likelihood of an 
attacker guessing the correct combination of session identifier and 
OTP value. Assuming OTPs with entropy about 32 bits, this means that 
the likelihood of succeeding with such an attack is about 1/2*48 due 
to the birthday paradox. Servers allowing session resumption for the 
basic variant MUST protect against such attacks, e.g., by keeping 
track of the rate of failed resumption attempts. 


6.3. Denial-of-Service Attacks 


An active attacker may replace the iteration count value in OTP TLVs 
sent by the peer to slow down an authentication server. 
Authentication servers SHOULD protect against this, e.g., by 
disregarding OTP TLVs with an iteration count value higher than some 
number that is preset or dynamically set (depending on load). 


6.4. The Use of Pepper 


As described in Section 4.8, the use of pepper will slow down an 
attacker’s search for a matching OTP. The ability to transfer a 
pepper value in encrypted form from the EAP server to the peer means 
that, even though there may be an initial computational cost for the 
EAP server to authenticate the peer, subsequent authentications will 
be efficient, while at the same time more secure, since a pre-shared, 
128-bit-long pepper value will not be easily found by an attacker. 
An attacker, observing an EAP-Request containing an OTP TLV 
calculated using a pepper chosen by the peer, may, however, depending 
on available resources, be able to successfully attack that 
particular EAP-POTP session, since it most likely will be based on a 
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relatively short pepper value or only an iteration count. Once the 
correct OTP has been found, eavesdropping on the EAP server’s Confirm 
TLV will potentially give the attacker access to the longer, server- 
provided pepper for the remaining lifetime of that pepper value. For 
this reason, initial exchanges with EAP servers SHOULD occur in a 
secure environment (e.g., in a PEAPv2 tunnel offering cryptographic 
binding with inner EAP methods). If initial exchanges do not occur 
in a secure environment, the iteration count MUST be significantly 
higher than for messages where a pre-shared pepper is used. The 
lifetime of the shared pepper must also be calculated with this in 
mind. Finally, the peer and the EAP server MUST store the pepper 
value securely and associated with the user. 


5. The Race Attack 


In the case of fragmentation of EAP messages, it is possible (in the 
basic variant of this method) for an attacker to listen to most of an 
OTP, guess the remainder, and then race the legitimate user to 
complete the authentication. Conforming backend authentication 
server implementations MUST protect against this race condition. One 
defense against this attack is outlined below and borrowed from [14]; 
implementations MAY use this approach or MAY select an alternative 
defense. Note that the described defense relies on the user 
providing the identity in response to an initial Identity EAP- 
Request. 


One possible defense is to prevent a user from starting multiple 
simultaneous authentication sessions. This means that once the 
legitimate user has initiated authentication, an attacker would be 
blocked until the first authentication process has completed. In 
this approach, a timeout is necessary to thwart a denial-of-service 
attack. 


IANA Considerations 
1. General 


This document is a description of a general EAP method for OTP 
tokens. It also defines EAP method 32 as a profile of the general 
method. Extending the set of EAP-POTP TLVs or the set of EAP-POTP 
cryptographic algorithms shall be seen as revisions of the protocol 
and hence shall require an RFC that updates or obsoletes this 
document. 
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7.2. Cryptographic Algorithm Identifier Octets 


A new registry for EAP-POTP cryptographic algorithm identifier octets 
has been created. The initial contents of this registry are as 
specified in Section 4.11.16. 


Assignment of new values for hash algorithms, encryption algorithms, 
and MAC algorithms in the Crypto Algorithm TLV MUST be done through 
IANA with "Specification Required" and "IESG Approval" (see [9] for 
the meaning of these terms). 


8. Intellectual Property Considerations 


RSA, RSA Security, and SecurID are either registered trademarks or 
trademarks of RSA Security Inc. in the United States and/or other 
countries. The names of other products and services mentioned may be 
the trademarks of their respective owners. 
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Appendix A. Profile of EAP-POTP for RSA SecurID 


Note: The RSA SecurID product is a hardware token card (or software 
emulation thereof) produced by RSA Security Inc., which is used for 
end-user authentication. 


The EAP method type identifier for the RSA SecurID profile of EAP- 
POTP is 32. 


Peers and EAP servers implementing the SecurID profile of EAP-POTP 
SHALL conform to all EAP-POTP normative requirements in this 
Document. In addition, the New PIN TLV and the Protected TLV MUST be 
supported by peers. 
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Appendix B. Examples of EAP-POTP Exchanges 


This appendix is non-normative. In the examples, "V1", "V2", "V3", 
etc., stand for arbitrary values of the correct type. 


B.1. Basic Mode, Unilateral Authentication 


This mode should only be used within a secured tunnel. The peer 
identifies itself with a User Identifier TLV. 


Peer EAP server 


<- EAP-Request 
Type=Identity 


EAP-Response -> 
Type=Identity 


<- EAP-Request 
Type=OTP-X 


Version TLV: 
Highest=0, Lowest=0 


OTP TLV: 
P=0,C=0,N=0, T=0, E=0, R=0 


EAP-Response -> 
Type=OTP-X 


Version TLV: 
Highest=0 


OTP TLV: 
P=0,C=0,N=0, T=0, E=0, R=0 
Authentication Data=V1 


User Identifier TLV: 
User Identifier=V2 


<- EAP-Success 
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B.2. Basic Mode, Session Resumption 


This example illustrates successful resumption of a basic mode 
session. It must be carried out only in a protected tunnel. 


Peer EAP server 


<- EAP-Request 
Type=Identity 


EAP-Response -> 
Type=Identity 


<- EAP-Request 
Type=OTP-X 


Version TLV: 
Highest=0, Lowest=0 


OTP TLV: 
P=0,C=0,N=0, T=0, E=0, R=0 


Server-Info TLV: 
N=0 
Session Identifier=V1 
Server Identifier=V2 
Nonce=V3 

EAP-Response -> 

Type=OTP-X 


Version TLV: 
Highest=0 


Resume TLV: 
Session Identifier=V4 (indicating earlier, basic mode, session) 


Authentication Data=V5 


<- EAP-Success 
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B.3. Mutual Authentication without Session Resumption 


In this case, the peer uses the token key identifier, in addition to 
the user identifier. The initial EAP-Identity exchange may also 
provide user information, or may be restricted to only general domain 
information. Pepper is not used, but will be used in a subsequent 
session since the server provides the peer with an encrypted pepper 
in its Confirm TLV. Absence of the Crypto Algorithm TLV indicates 
use of default cryptographic algorithms. 


Peer EAP server 


<- EAP-Request 
Type=Identity 


EAP-Response -> 
Type=Identity 


<- EAP-Request 
Type=OTP-X 


Version TLV: 
Highest=0, Lowest=0 


Server-Info TLV: 

N=0 

Session Identifier=V1 
Server Identifier=V2 
Nonce=V3 


OTP TLV: 
P=1,C=0,N=0,T=0,E=0,R=0 
Pepper Length=0 
Iteration Count=V4 


EAP-Response -> 
Type=0TP-X 


Version TLV: 
Highest=0 


OTP TLV: 

P=1, C=0,N=0, T=0, E=0, R=0 
Pepper Length=0 
Iteration Count=V4 
Authentication Data=V5 
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User Identifier TLV: 
User Identifier=V6 


Token Key Identifier TLV: 
Token Key Identifier=V"7 


<- EAP-Request 
Type=OTP-X 


Confirm TLV: 

c=0 

Authentication Data=V8 
Pepper Identifier=V9 
Encrypted Pepper=V10 


EAP-Response -> 
Type=OTP-X 


Confirm TLV: 
(no data) 


<- EAP-Success 
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B.4. Mutual Authentication with Transfer of Pepper 


The difference between this example and the previous one is that the 

peer makes use of an existing pepper in the PBKDF2 computation. The 

EAP server provides a new pepper to the peer in the Confirm TLV. 

Note that the peer had not been able to use a pepper in the response 

calculation unless it had found the existing pepper, since the server 
specified a maximum (new) pepper length of zero. 


Peer EAP server 


<- EAP-Request 
Type=Identity 


EAP-Response -> 
Type=Identity 


<- EAP-Request 
Type=0TP-X 


Version TLV: 
Highest=0, Lowest=0 


Server-Info TLV: 

N=0 

Session Identifier=V1 
Server Identifier=V2 
Nonce=V3 


OTP TLV: 
P=1,C=0,N=0,T=0,E=0,R=0 
Pepper Length=0 
Iteration Count=V4 


EAP-Response -> 
Type=OTP-X 


Version TLV: 
Highest=0 


OTP TLV: 

P=1,C=0,N=0, T=0, E=0, R=0 
Pepper Length=V5 

Iteration Count=V6 
Authentication Data=V7 
(includes a pepper identifier) 
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User Identifier TLV: 
User Identifier=V8 


Token Key Identifier TLV: 
Token Key Identifier=V9 


<- EAP-Request 
Type=OTP-X 


Confirm TLV: 

C=0 

Authentication Data=V10 
Pepper Identifier=V11 
Encrypted Pepper=V12 


EAP-Response -> 
Type=OTP-X 


Confirm TLV: 
(no data) 


<- EAP-Success 
B.5. Failed Mutual Authentication 


This example differs from the previous one in that the peer is not 
able to authenticate the server. Therefore, it sends an empty EAP- 
Response of type POTP-X, which the EAP server acknowledges by 
responding with an EAP-Failure. Pepper is not used. 


Peer EAP server 


<- EAP-Request 
Type=Identity 


EAP-Response -> 
Type=Identity 


<- EAP-Request 
Type=OTP-X 


Version TLV: 
Highest=0, Lowest=0 


OTP TLV: 

P=1,C=0,N=0, T=0, E=0, R=0 
Pepper Length=V1 
Iteration Count=V2 
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Server-Info TLV: 

N=0 

Session Identifier=V3 
Server Identifier=V4 
Nonce=V5 


EAP-Response -> 
Type=OTP-X 


Version TLV: 
Highest=0 


OTP TLV: 

P=1, C=0, N=0, T=0, E=0, R=0 
Pepper Length=V1 
Iteration Count=V2 
Authentication Data=V6 


User Identifier TLV: 
User Identifier=V7 


Token Key Identifier TLV: 
Token Key Identifier=V8 


<- EAP-Request 
Type=OTP-X 


Confirm TLV: 
C=0 
Authentication Data=V9 


EAP-Response -> 
Type=OTP-X 


(no data) 
<- EAP-Failure 
B.6. Session Resumption 
This example illustrates successful session resumption. 
Peer EAP server 


<- EAP-Request 
Type=Identity 
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EAP-Response -> 
Type=Identity 


<- EAP-Request 
Type=0TP-X 


Version TLV: 
Highest=0, Lowest=0 


OTP TLV: 
P=1,C=0,N=0,T=0,E=0,R=0 
Pepper Length=V1 
Iteration Count=V2 


Server-Info TLV: 

N=0 

Session Identifier=V3 
Server Identifier=V4 
Nonce=V5 


EAP-Response -> 
Type=OTP-X 


Version TLV: 
Highest=0 


Resume TLV: 
Session Identifier=V6 (indicating earlier, protected mode, session) 
Authentication Data=V7 


<- EAP-Request 
Type=0TP-X 


Confirm TLV: 
C=0 
Authentication Data=V8 
EAP-Response -> 
Type=OTP-X 
Confirm TLV: 
(no data) 


<- EAP-Success 
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B.7. Failed Session Resumption 


This example illustrates a failed session resumption, followed by a 
complete mutual authentication. The user is identified through the 
User Identifier TLV. The client is able to reuse an older pepper. 
The server sends a new pepper for subsequent use in its Confirm TLV. 
The server suggests some non-default cryptographic algorithms, but 
the client only supports the default ones. 


Peer EAP server 


<- EAP-Request 
Type=Identity 


EAP-Response -> 
Type=Identity 


<- EAP-Request 
Type=0TP-X 


Version TLV: 
Highest=0, Lowest=0 


OTP TLV: 

P=1,C=0,N=0, T=0, E=0, R=0 
Pepper Length=V1 
Iteration Count=V2 


Server-Info TLV: 

N=0 

Session Identifier=V3 
Server Identifier=V4 
Nonce=V5 


Crypto Algorithm TLV: 
Hash Alg. Length=V6 
Hash Algorithms=V7 
Encr. Alg. Length=V8 
Encr. Algorithms=V9 
MAC Alg. Length=V10 
MAC Algorithms=V11 


EAP-Response -> 
Type=OTP-X 


Version TLV: 
Highest=0 
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Resume TLV: 
Session Identifier=V12 (indicating earlier session) 
Authentication Data=V13 


<- EAP-Request 
Type=0TP-X 


OTP TLV: 
P=1,C=0,N=0,T=0,E=0,R=0 
Pepper Length=V14 
Iteration Count=V15 


Server-Info TLV: 

N=1 (no resumption) 
Session Identifier=V3 
Server Identifier=V4 
Nonce=V16 


EAP-Response -> 
Type=0TP-X 


OTP TLV: 

P=1,C=0,N=1,T=1,E=0,R=0 

Pepper Length=V17 

Iteration Count=V18 

Authentication Data=V19 (with pepper identifier) 


User Identifier TLV: 
User Identifier=V20 


<- EAP-Request 
Type=OTP-X 


Confirm TLV: 
Cc=0 
Authentication Data=V21 
Pepper Identifier=V22 
Encrypted Pepper=V23 
EAP-Response -> 
Type=OTP-X 


Confirm TLV: 
(no data) 


<- EAP-Success 
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.8. Mutual Authentication, and New PIN Requested. 


In this example, the user is also requested to select a new PIN. The 
new PIN is allowed to be alphanumeric, and must be at least 6 
characters long. The user selects another PIN than the one suggested 
by the server. The token key is identified through a combination of 
the user identifier and the token key identifier. While waiting for 
the user input, to avoid network timeouts, the peer sends an EAP- 
Response containing a Keep-Alive TLV to the EAP server. The EAP 
server responds by sending an EAP-Request containing a Keep-Alive TLV 
back to the peer. Note that all TLVs exchanged after the Confirm TLV 
exchange are wrapped in the Protected TLV. Absence of the Crypto 
Algorithm TLV indicates use of default cryptographic algorithms. 


Peer EAP server 


<- EAP-Request 
Type=Identity 


EAP-Response -> 
Type=Identity 


<- EAP-Request 
Type=OTP-X 


Version TLV: 
Highest=0, Lowest=0 


OTP TLV: 

P=1,C=0,N=0, T=0, E=0, R=0 
Pepper Length=V1 
Iteration Count=V2 


Server-Info TLV: 

N=0 

Session Identifier=V3 
Server Identifier=V4 
Nonce=V5 


EAP-Response -> 
Type=0TP-X 


Version TLV: 
Highest=0 


OTP TLV: 
P=1,C=0,N=0,T=0,E=0,R=0 
Pepper Length=V6 
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Iteration Count=V7 
Authentication Data=V8 (with pepper identifier) 


User Identifier TLV: 
User Identifier=V9 


Token Key Identifier TLV: 
Token Key Identifier=V10 


<- EAP-Request 
Type=OTP-X 


Confirm TLV: 
C=1 
Authentication Data=V11 


EAP-Response -> 
Type=0TP-X 


Confirm TLV: 
(no data) 


<- EAP-Request 
Type=0TP-X 


Protected TLV: 
MAC=V12 

IV=V13 

Encrypted TLVs=V14 
(Contains: 

New PIN TLV: 

Q=0, A=1 

PIN=V15 

Min. PIN Length=6) 


EAP-Response -> 
Type=0TP-X 


Protected TLV: 
MAC=V16 

IV=V17 

Encrypted TLVs=V18 
(Contains: 
Keep-Alive TLV: 
(no data) ) 


<- EAP-Request 
Type=0TP-X 
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Protected TLV: 
MAC=V19 

IV=V20 

Encrypted TLVs=V21 
(Contains: 
Keep-Alive TLV: 
(no data)) 


EAP-Response -> 
Type=OTP-X 


Protected TLV: 
MAC=V22 

IV=V23 

Encrypted TLVs=V24 
(Contains: 

New PIN TLV: 

Q=0, A=0 

PIN=V25) 


<- EAP-Request 
Type=OTP-X 


Protected TLV: 

MAC=V26 

IV=V27 

Encrypted TLVs=V28 
(Contains: 

OTP TLV: 

P=1,C=0,N=0, T=0, E=0, R=0 
Pepper Length=V1 
Iteration Count=V2) 


EAP-Response -> 
Type=0TP-X 


Protected TLV 

MAC=V29 

IV=V30 

Encrypted TLVs=V31 
(Contains: 

OTP TLV: 
P=1,C=0,N=0,T=0,E=0,R=0 
Pepper Length=V6 
Iteration Count=V7 
Authentication Data=V31) 
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<- EAP-Request 
Type=0TP-X 


Protected TLV 

MAC=V32 

IV=V33 

Encrypted TLVs=V34 
(Contains: 

Confirm TLV: 

C=0 

Authentication Data=V35) 


EAP-Response -> 
Type=OTP-X 


Protected TLV 
MAC=V36 

IV=V37 

Encrypted TLVs=V38 
(Contains: 

Confirm TLV: 

(no data) ) 


<- EAP-Success 
B.9. Use of Next OTP Mode 


In this example, the peer is requested to provide a second OTP to the 
EAP server. 


Peer EAP server 


<- EAP-Request 
Type=Identity 


EAP-Response -> 
Type=Identity 


<- EAP-Request 
Type=OTP-X 


Version TLV: 
Highest=0, Lowest=0 


OTP TLV: 
P=1,C=0,N=0,T=0,E=0,R=0 
Pepper Length=V1 
Iteration Count=V2 
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Server-Info TLV: 

N=0 

Session Identifier=V3 
Server Identifier=V4 
Nonce=V5 


EAP-Response -> 
Type=OTP-X 


Version TLV: 
Highest=0 


OTP TLV: 

P=1,C=0,N=0, T=0, E=0, R=0 
Pepper Length=V6 
Iteration Count=V7 
Authentication Data=V8 


User Identifier TLV: 
User Identifier=V9 


<- EAP-Request 
Type=OTP-X 


OTP TLV: 
P=1,C=0,N=1,T=1,E=0,R=0 
Pepper Length=V1 
Iteration Count=V2 


EAP-Response -> 
Type=0TP-X 


OTP TLV: 
P=1,C=0,N=1,T=1,E=0,R=0 
Pepper Length=V6 
Iteration Count=V7 
Authentication Data=V10 


<- EAP-Request 
Type=OTP-X 


Confirm TLV: 
C=0 
Authentication Data=V11 


EAP-Response -> 
Type=OTP-X 
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Confirm TLV: 
(no data) 


<- EAP-Success 
Appendix C. Use of the MPPE-Send/Receive-Key RADIUS Attributes 
C.1. Introduction 


This section describes how to populate the MPPE-Send-Key and the 
MPPE-Receive-Key RADIUS attributes defined in [19], using an MSK 
established in EAP-POTP. 


C.2. MPPE Key Attribute Population 


Once the EAP-POTP MSK has been generated, it is used as follows to 
populate the MPPE-Send-Key and the MPPE-Receive-Key attributes: 


Use the initial 32 octets of the MSK as the value for the "Key" sub- 
field in the plaintext "String" field of the MPPE-Send-Key attribute, 
and use the final 32 octets of the MSK as the "Key" sub-field in the 
plaintext "String" field of the MPPE-Receive-Key attribute (Note: 
"Send" and "Receive" here refer to the Authenticator; for the peer, 
they are reversed). 


Appendix D. Key Strength Considerations 
D.1. Introduction 


As described in Section 6, the strength of keys generated in EAP-POTP 


protected mode depends on a number of factors. This appendix 
provides examples of actual key strengths achieved under various 
assumptions. 


It should be noted that, while some of the examples indicate that the 
strength of generated keys is relatively weak, the strength applies 
only to those EAP-POTP sessions between a peer and an EAP server that 
do not share a pepper. Once a pepper, provided by an EAP server to a 
peer, has been established, future sessions using this pepper will 
provide full-strength keys. 
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D.2. Example 1: 6-Digit One-Time Passwords 
In this example we assume the following: 
OTPs are six decimal digits long; 
4-digit PINs are added to generated OTPs; and 
OTP hardening (iteration count and pepper searching combined) 
effectively adds 10 bits of entropy. One way of achieving this 


without use of pepper searching is to have the iteration count in 
PBKDF2 set to 1,000,000. 


The effective key strength then becomes roughly: 
log_2(10**6) + log_2(10**4) + log_2(2**10) = 43 bits 


The above assumes that the entropy of the underlying shared secret is 
>43 bits and that there are no other weaknesses in the OTP algorithm. 


D.3. Example 2: 8-Digit One-Time Passwords 
In this example we assume the following: 
OTPs are eight decimal digits long; 
4-character alphanumeric PINs are added to generated OTPs; and 


OTP hardening (iteration count and pepper searching combined) 
effectively adds 10 bits of entropy. 


The effective key strength then becomes roughly: 
log_2(10**8) + log_2(26**4) + log_2(2**10) = 55 bits 


The above assumes that the entropy of the underlying shared secret is 
>55 bits and that there are no other weaknesses in the OTP algorithm. 
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